Beyond Clean Code Dogma - Why Your Engineering Team Should Obsess Over the Delivery Trinity Instead

After 20+ years shipping software, I've learned that obsessing over clean code dogma can actually slow you down. Here's what to focus on instead.

After 20+ years shipping software in delivery-obsessed environments—from early-stage startups to scale-ups—I've seen the same pattern repeat: brilliant engineers get lost in the weeds of "best practices" and forget why we're here in the first place.

We're not here to write the cleanest code on the planet.

We're not here to achieve 100% test coverage.

We're not here to debate monoliths vs microservices for the sake of architectural purity.

We're here to deliver value through the product—fast, reliably, and iteratively.

Everything else is just a tool.

In a product-focused company, the engineering team's entire reason for existing is to move the business forward by shipping working software that users actually use. To do that, we need to build efficiently. And when you strip away all the noise, efficient delivery boils down to three things I call the Delivery Trinity:

  1. Ability to produce code (how fast and effectively can we turn ideas into working software—now turbocharged by AI and "vibe coding").
  2. Confidence to release (do we actually know this change works, won't break anything, and has no nasty side effects?).
  3. Ability to release code (how frictionless is the path from my machine → CI/CD → production, with safe rollbacks when needed).

Everything we do—dev environments, code reviews, automated tests, QA processes, infrastructure, clean code standards, linters, architecture decisions—exists only to strengthen one or more of these three pillars of the Delivery Trinity. The moment any practice stops serving the Trinity, it becomes overhead.

Here's where the industry loses the plot.

Most engineers (and many engineering leaders) fall into one of two camps when thinking about how to get better:

Camp 1 (Dogmatic): Master every individual process to perfection. "We must have TDD. We must write perfectly clean code. We must have a dedicated QA team. We must follow SOLID religiously." Passionate debates erupt over the purity of the practice itself.

Camp 2 (Pragmatic): Do the minimum set of processes that reliably gives us the Delivery Trinity right now. Confidence to release? Sometimes that's a full test pyramid + QA. Sometimes it's a single integration test. Sometimes it's "I ran it locally and it's obvious." As long as confidence is high and velocity stays strong, the exact recipe doesn't matter.

I'm firmly in Camp 2.

Don't misunderstand me—clean code, automated testing, code reviews, and robust CI/CD are fantastic tools. They've saved my ass countless times. But they are servants, not masters. When a team starts treating them as non-negotiable dogma, they lose sight of the actual goal: strengthening the Delivery Trinity so the business can move faster.

I've watched teams argue for weeks about whether a new feature "truly follows clean code principles" while the market window closed. I've seen others ship twice as fast with lighter processes because they stayed laser-focused on "Can we produce it? Are we confident? Can we release it safely?"

The pragmatic approach doesn't mean "ship crap." It means being ruthless about asking: For our current team size, experience level, tech stack, and business pressure, what is the smallest set of practices that keeps the Delivery Trinity strong?

And because teams constantly evolve—people join or leave, tech changes, product needs shift—the answer is never static. The real skill of building a strong engineering organization isn't installing the latest "best practice" religion. It's continuously re-balancing the individual factors so the Delivery Trinity stays robust.

So the next time you catch yourself (or your team) in a heated debate about clean code, TDD, or any other sacred cow, pause and ask:

"Does this practice actually make us better at producing code, gaining release confidence, or shipping safely—right now?"

If the honest answer is "not really," you've just found dogma masquerading as progress.

Focus on the Delivery Trinity. Treat everything else as the tool it is. Ship value. Repeat.

That's how you build software teams that actually matter.