Martin Stühmer: CTO & DevOps Engineer

Who I Am

I’m Martin, CTO at Integrated Worlds GmbH in the Stuttgart region. I’ve been writing production .NET code since Framework 2.0 — back when SOAP was still considered modern and ORMs were a heated debate. A lot has changed since then. My opinions have changed too, usually because I was wrong about something.

Before Integrated Worlds, I was Director of Consulting Services at CGI, leading teams through architecture decisions and digital transformation projects across multiple industries. These days I set technology strategy and stay close enough to the code to feel the consequences of those decisions firsthand.

I’m a Microsoft Certified Trainer and IHK-certified instructor, maintain several open-source NuGet packages, and write about what I’ve actually learned rather than what sounds good in theory.

LinkedIn · GitHub · Bluesky

What I Know Well

Nearly two decades of production work leaves marks. Here’s where I’ve built up depth and, frankly, strong opinions:

.NET and C# — I’ve tracked this ecosystem from the framework era to .NET 10. Source generators, Roslyn analyzers, performance engineering, testing strategies, static analysis. I know what actually improved over the years and what just changed names.

Cloud-native architecture on Azure — AKS at scale, multi-cluster networking, zero-downtime upgrade strategies, cost governance, observability. I’ve spent enough time in Azure to know the gap between what it can do and what you should actually use.

DevOps and supply-chain security — GitHub Actions, dependency management, container security, Bicep-based infrastructure compliance. The organisational side matters as much as the tooling.

Application security and privacy — Azure Key Vault, managed identities, GDPR-relevant .NET patterns, data minimisation, AI coding tool content exclusions. Security that works in practice, not just in architecture diagrams.

Engineering culture — What AI coding assistants actually change about software quality (less than the hype, more than the skeptics admit), how to introduce static analysis without poisoning team morale, and when “best practices” are earned principles versus cargo-cult repetition.

How I Work

As CTO I stay close to the code. I write, review PRs, debug production issues, and mentor — because technology leadership that operates purely from a distance eventually loses touch with the real cost of decisions.

As a trainer I focus on fundamentals that outlast the current framework cycle. Static analysis, testing discipline, performance patterns, maintainable architecture. The things that prevent fires, not just the things that look good in a job posting.

As an open-source maintainer I publish packages that solve problems I’ve hit repeatedly. Knowing that strangers depend on your code is one of the better ways to raise your standards.

What I’ve Learned the Hard Way

I’ve over-engineered systems that should have been simple. I bet on Silverlight and WCF. I built “flexible” architectures that were really just complicated ones. I’ve shipped code I’m not proud of.

Here’s what held up after all that:

Quality isn’t optional — analyzers find bugs in milliseconds, tests prevent regressions, and neither is slower than a production incident
Fundamentals outlast frameworks — the patterns and principles stick around long after the tools are deprecated
Context beats dogma — “best practices” always depend on your team, domain, and actual constraints
Evidence beats intuition — measure, benchmark, validate; don’t just decide
Pragmatism wins — architecture that ships beats architecture that’s perfect on paper

What I Write About

Everything here comes from production systems and real teams, not documentation rewrites. I’m skeptical of buzzword-driven development and allergic to advice that’s never been tested under load or deadline. If something doesn’t hold up, I’ll say so.

The topics I keep returning to: .NET and C# performance and evolution, Azure and AKS architecture decisions, DevOps and supply-chain risk, application security and GDPR implementation, what AI coding tools actually change (and what they don’t), and the economics of technical debt and code quality.

I write for developers, architects, and operators who maintain production systems and care about getting it right — not just getting it shipped.

The code you create is a valuable legacy, so it’s important to build it carefully.

Published blogs

My Analyzer Shipped Without Checking Its Own Source

NetEvolve.Analyzer enforces null-check idioms and file organization on other people’s code, but had never run against its own. Fixing that surfaced 39 warnings, a silent Visual Studio MEF failure, and a follow-up NE0008 bug where DateOnly and TimeOnly got flagged blind to which target framework actually has them, the same multi-targeting blindness in a different corner of the codebase.

Cyber Resilience Act for .NET Library Authors: Read the Fine Print

The EU Cyber Resilience Act’s headline deadline is December 2027, but the reporting clock starts more than a year earlier. Article 14 vulnerability reporting applies from September 2026. Here is the engineering map I built for my own NuGet release pipeline: what the CRA regulates, the 24/72-hour cadence, SBOM tooling for .NET, and where the open-source carve-out holds.

Incremental Source Generators Done Right: Ship It Without Breaking Consumers

Parts 1 through 3 of this series made the generator correct, incremental, and proven by tests. None of it reaches a single consumer if the NuGet package is laid out wrong — and the failure modes are silent: a DLL in lib/ instead of analyzers/dotnet/cs simply never loads, a missing dependency throws only inside the compiler, and a marker attribute delivered carelessly breaks InternalsVisibleTo in ways users cannot diagnose. This final part covers the packaging contract: the netstandard2.0 rule, the package layout, dependency bundling, attribute delivery, debugging the shipped bits, and the analyzer hygiene rules that keep you honest.

Incremental Source Generators Done Right: Prove the Cache Hits

You followed the equality rules, you shaped the pipeline correctly, and your generator still might be re-running on every keystroke — because nobody ever asked the driver. Roslyn records exactly why each pipeline step re-executed, and you can assert against those reasons in a plain xUnit test. This is the test that turns “my generator is incremental” from a claim into a regression-protected fact, plus the catalog of anti-patterns it catches in the wild.

Incremental Source Generators Done Right: Pipeline Patterns That Scale

Part 1 of this series established the equality contract: every value flowing through an incremental generator pipeline must be comparable by value, or the cache misses and the generator re-runs on every keystroke. This part is about the pipeline itself — ForAttributeWithMetadataName as the entry point, where to filter, where to transform, how to combine providers without accidentally subscribing to the entire Compilation, and the Collect trap that silently breaks everything you fixed in part 1. It ends with a complete worked generator you can steal.