Code Quality and Clean Code Principles

“Quality” is the word teams reach for when a codebase frustrates them and nobody wants to argue about specifics. The articles in this collection try to put specifics back: which metric actually predicts maintainability, which Clean Code rule survives contact with a real change request, which analyzer warning is signal and which is decoration. Quality without a measurement attached is taste, and taste does not survive a team rotation.

The metric-focused content treats cyclomatic complexity, maintainability index, and class coupling as imperfect proxies rather than thresholds. The same number means different things in a CQRS handler and in a parser. Articles cover how to configure code metrics in Visual Studio and dotnet tooling so the output reflects intent — and when to ignore the numbers because the context invalidates them.

Analyzer and nullable-reference-type content sits at the boundary between style and correctness. Turning on TreatWarningsAsErrors, adopting <Nullable>enable</Nullable> in a legacy project, and choosing which Roslyn rules to enforce in .editorconfig are not aesthetic choices — they decide what kind of bug your CI is allowed to ship. The articles walk through staged adoption strategies rather than the all-or-nothing flag flip that most teams attempt and abandon.

Testing strategy gets the same treatment. Coverage percentages are easy to game; mutation testing exposes assertions that test nothing. Articles examine where mutation testing pays for its runtime cost, where it produces noise, and how to read the surviving mutants without rewriting the entire suite.

The social dimension runs through everything. Quality practices that one engineer pushes through review get reverted by the next rotation unless they live in tooling. The recurring theme is moving quality out of opinion and into configuration that fails the build — so the standard outlives whoever set it.

Why Real Professionals Will Never Be Replaced by AI

The elephant everyone ignores: AI can generate code faster than you can type. GitHub Copilot autocompletes entire functions. ChatGPT builds APIs from prompts. Typing is dead. So why will real professionals never be replaced? Because “vibe coding”—describe what you want, ship what AI generates—is a productivity illusion that collapses spectacularly in production. When code generation becomes trivial, understanding what that code costs, where it fails, why it breaks under load becomes everything. AI generates syntax. Professionals understand execution, failure modes, operational cost, and production consequences. The differentiator isn’t typing speed—it’s mastering the feedback loop: write code, watch it fail, understand why, refine thinking. This discipline can’t be automated. Prompt engineers generate code. Real professionals ensure it survives contact with reality.

Most Software Teams Are Lying to Themselves—2026 Needs to Be Different

Happy New Year 2026! 🎉

Fix one piece of technical debt this week—not next quarter. .NET 10, analyzers, and tests are ready; discipline is the only missing part.

Power of Ten Rules: More Relevant Than Ever for .NET

Gerard Holzmann’s Power of Ten rules prevented spacecraft failures and exposed Toyota’s fatal throttle bugs. Four rules transfer directly to C# with superior enforcement. Three become irrelevant thanks to the managed runtime.

The verdict: These principles aren’t just valid. They’re finally enforceable without heroic manual effort.

Code Metrics: Beyond the Numbers Game

Code metrics have become a standard feature in modern development environments, yet their implementation and interpretation often leave much to be desired. While Visual Studio and .NET provide comprehensive code metrics analysis, the way these metrics are configured, presented, and (more critically) acted upon reveals a fundamental disconnect between measurement and meaningful improvement.

What code metrics actually measure, how to configure them properly, and (more importantly) why blindly following thresholds without understanding context is, frankly, a recipe for misguided refactoring efforts that waste your team’s time and actively damage your codebase.

.NET 10: Boring by Design, Reliable by Default

Microsoft wants you to believe .NET 10 is boring. They’re right — and that’s the best news we’ve had in years.

.NET 10 is here, and for once, Microsoft didn’t oversell it. LTS support through 2028, JIT improvements that actually matter, and C# 14 features that won’t rewrite your architecture. Here’s what you need to know before migrating.