One of the most corrosive things in software teams isn’t bugs themselves — it’s inconsistency in how we react to them.
One week, the message is “this has to be perfect — why are we still seeing defects?”
The next week, under delivery pressure, it flips to “just get it done, don’t bother me with the details.”
Developers feel this oscillation immediately. They learn that quality standards are not stable, that visibility can be risky, and that the safest strategy is often silence. Over time, code quality becomes something people intuit rather than manage—a dark art shaped by mood, deadlines, and whoever is asking the question that day.
I’ve come to believe that this is not a people problem. It’s a systems problem.
The Deming Insight
The alternative draws heavily on the work of W. Edwards Deming, whose ideas fundamentally reshaped manufacturing in the twentieth century—most visibly in Toyota’s transformation of automotive production. Deming showed that quality does not emerge from exhortation, inspection, or pressure on individuals. It emerges from stable processes, clear feedback loops, and a relentless focus on reducing unwanted variation. His insight was that most defects are not caused by bad workers, but by systems that make errors likely and hide their signals until it is too late.
What made Deming’s work transformative was that it replaced blame with learning. By measuring process behaviour over time, manufacturers could distinguish normal variation from genuine warning signs, address root causes instead of symptoms, and steadily lift quality without sacrificing productivity. That same logic applies remarkably well to software, which is every bit as complex, interdependent, and sensitive to hidden variation as a modern production line.
What “Healthy” Looks Like
Seen through this lens, code quality stops being about demanding perfection or tolerating chaos. It becomes about defining what “healthy” looks like right now, and then watching how the system behaves against that expectation.
A proof of concept is allowed to be rough. An MVP should be more stable. A beta should show tightening control, and a production system should exhibit very little tolerance for high-severity defects, especially in sensitive areas like security, data handling, and permissions. The key is not pretending all stages are equal, but being explicit about how expectations evolve.
This is where quality stops being abstract. Instead of asking “are there bugs?”, the questions become far more useful:
- Are we seeing sudden spikes, or steady behaviour?
- Are high-severity defects becoming rarer?
- Are the same classes of issues repeating, or are they being designed out?
- Is the tolerance band narrowing as the system matures?
Those answers live in trends, not snapshots. They tell you whether the system is learning.
When the Trend Says “No”
We experienced this directly with a presenter-led training application—stable, well-understood—that we wanted to extend to cover additional programs while reusing the existing infrastructure for classes, students, and assessments.
Bug counts rose quickly. At first, we assumed this was normal turbulence; the codebase would stabilise once we worked through the backlog. But it didn’t. As fast as we closed one issue, another appeared. The trend line stayed flat—or worse.
That was the signal. Tactical bug fixing wasn’t reducing defects; we were playing whack-a-mole with symptoms. So we stepped back and examined the structure. We found two design assumptions from the original system that didn’t hold in the extended context. The fixes were straightforward once we saw them.
Within weeks, the defect rate dropped and stayed down.
The metrics didn’t tell us what was wrong. But they told us our current approach wasn’t working—early enough to change course before we’d wasted months on tactical fixes that would never have stabilised the system.
Non-Punitive by Design
Crucially, this approach is non-punitive by design. The measurements apply to the application, not to individual developers. Defects are treated as signals, not indictments. When people know that surfacing problems won’t be used against them, they surface them earlier—and early signals are gold.
The alternative is well-documented. GE’s “rank and yank” and Microsoft’s stack ranking required managers to identify the bottom performers for elimination, regardless of how the team was actually performing. The result wasn’t quality—it was political survival behaviour dressed up as productivity. Developers stopped helping colleagues. People avoided ambitious projects. The best engineers left for environments where they could build things instead of defending their position.
The metrics looked healthy. The culture was dying.
A system-focused approach inverts this. When defects belong to the codebase rather than to individuals, collaboration becomes rational and surfacing problems becomes safe. The question shifts from “who should we blame?” to “is the system improving?” One of those questions has an answer. The other only has victims.
The Shift
Once teams experience the shift away from blame, something changes. Quality discussions become calmer and more factual. Testing stops being a defensive exercise and becomes a shared feedback loop. Developers can explain, with evidence, why a system is healthy for its stage, and leaders can see progress without demanding the impossible.
That’s the moment when code quality stops being a dark art.
It becomes a system: observable, discussable, and steadily improvable. Not through pressure or heroics, but through consistency, clarity, and continuous improvement—the very things complex systems respond to best.
In the end, metrics don’t just measure behaviour—they create it.
