When people talk about software quality, they often pick a single discipline to champion. “We need more automated tests!” Or, “If only we had world-class QA!” Or, “The real issue is bad requirements.” There’s truth in all of these, but here’s the catch: excelling in one layer of delivery doesn’t guarantee high-quality outcomes. What actually works is being pretty good across all the layers.
Let me explain.
The Trap of Ever-Decreasing Returns
Each area of software delivery has a point of diminishing returns. Take automated tests. Writing enough unit tests to catch the obvious issues is straightforward. Going further to cover edge cases and complex scenarios is still worthwhile, but it takes noticeably more effort. And pushing beyond that—trying to catch every possible bug—consumes huge amounts of time while delivering far less improvement. You might spend twice the effort to squash just a handful of additional defects.
The same pattern shows up in QA, observability, CI/CD pipelines, even in how clearly you define requirements. The first steps give you big wins. After that, the effort-to-value curve falls off sharply.
Layers That Catch Two Thirds
Now imagine each layer of your delivery process as a filter. It doesn’t catch all the bugs, but it removes about two thirds of them. That’s not a magical number—it just illustrates that being “quite good” at something is usually enough to prevent a big chunk of defects from leaking through.
- Collaborative programming catches many mistakes before they’re committed.
- Unit tests stop obvious logic errors and help with regression.
- Developer-written integration tests flush out broken interactions and help further with regression.
- CI/CD practices make sure we minimise the risk of any code change.
- Observability shines a light on what slipped through.
- A skilled QA team makes sure everything is being tested somehow somewhere.
- Clear work items prevent half-baked requirements.
- Strong direction aligns everyone on the goal, preventing task switching or thrashing.
- Ops and Sec Ops enable change instead of creating roadblocks, letting the team focus on ‘getting it done’.
Each one trims away another two thirds of potential problems.
Why Being “Quite Good” Is Enough
Here’s the magic: when you layer these practices, the effect multiplies. Two thirds gone at one stage, then two thirds of what’s left, and so on. By the time you’ve passed through multiple layers, only a tiny fraction of issues ever make it to production. And you didn’t have to push any one layer to the point of diminishing returns.
Compare that to pouring all your effort into just one area—say, exhaustive testing. You’ll eventually hit a wall where extra test effort barely reduces bugs, while the unchecked gaps in requirements, collaboration, or observability still let plenty of issues slip through.
How Many Bricks Can You Pull Out?
Think of these layers as bricks in a wall. No single brick makes the wall strong, but together they create something solid and resilient. Every team will have different strengths: maybe yours has excellent observability but weaker QA, or maybe your QA is outstanding but your work items are fuzzy. That’s normal.
The real question is: how many bricks can you pull out before the wall gives way?
Take a moment to look at your team’s delivery practices. Which of these layers are you confident in? And which ones don’t get enough attention? Every team is different, but the layers themselves rarely change. If a few bricks are missing, it’s only a matter of time before the gaps start to show.
Coding Daddy Dobbs 