The Traditional Quality Model Is Costing You More Than You Think
Why the traditional quality model is a debt machine and how to stop paying interest
Every team I've worked with underestimates the cost of finding bugs late. Not by a little, by orders of magnitude. The math is brutal, the pattern is predictable, and yet organisations keep repeating the same mistake: treating quality as a phase instead of a discipline.
Here's why that decision costs far more than anyone budgets for.
The Numbers Don't Lie
Most defects end up costing more than they would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business and lost development time.
— Kent Beck, Extreme Programming Explained
This isn't abstract philosophy. The numbers are real.
To understand why the costs increase in this manner, consider what happens to a single requirements error depending on when it gets found:
If you make a requirements error and find it during the requirements phase, it is inexpensive to fix. You merely change a portion of your requirements model. A change of this scope is on the order of $1
If you do not find it until the design stage, it is more expensive to fix. Not only do you have to change your analysis, but you also have to reevaluate and potentially modify the sections of your design based on the faulty analysis. This change is on the order of $10.
If you do not find the problem until programming, you need to update your analysis, design, and potentially scrap portions of your code, all because of a missed or misunderstood user requirement. This error is on the order of $100, because of all the wasted development time based on the faulty requirement.
Furthermore, if you find the error during the traditional testing stage, it is on the order of $1,000 to fix (you need to update your documentation and scrap/rewrite large portions of code).
Finally, if the error gets past you into production, you are looking at a repair cost on the order of $10,000+ to fix (you need to ship updated code, fix the database, restore old data, etc.).
That's a 10,000x cost multiplier from requirements to production. The same defect. Just found it later.
This isn't a testing problem. It's a timing problem.
The Traditional Quality Model — And Why It Fails
Most organisations I have seen operate with a version of the same model, and it looks something like this:
QA members tend to be less involved in early stages like planning and design.
Many architectural requirements and design flaws are not discovered and corrected until after a significant effort has been wasted on their implementation.
Less time to fix defects.
There is a great chance of “breaking” functionality due to last-minute fixes, jeopardising the release date.
Testing time gets shrunk and usually becomes a bottleneck.
Testing is a phase at the end of the development cycle.
Sound familiar? It should. This is the default in most organisations, and the consequences are entirely predictable every time. Bugs pile up, releases slip, teams burn out, and everyone points fingers at QA for "not catching it."
The uncomfortable truth is that QA can't catch what it was never involved in building. When testing is a phase at the end of a cycle, it inherits every bad decision made before it arrived.
Once you see these numbers clearly, the traditional model doesn't just look inefficient — it looks indefensible. That's what drives serious engineering organisations to rethink quality from the ground up.
The Questions This Forces Us to Ask
Once you accept the compounding cost of late defect detection, the right questions become obvious:
How do we detect defects earlier — or better yet, prevent them entirely?
How do we bring QA and testing activities into the earlier stages of the SDLC?
How do we reduce the total cost of development and testing?
How do we make the whole team — not just QA — responsible for quality?
These aren't QA questions. They are engineering leadership questions.
And the answers require more than better test coverage; they require a fundamentally different approach to how quality is embedded into the workflow.
So how do we actually achieve that?
Essentially, the development workflow should ensure that defects can be detected as early as possible. It is valuable to implement processes that enable the team to detect early and detect often.
Detect Early, Detect Often
In essence, processes and conventions should be designed around moving defect detection as early in the workflow and as close to the developer’s coding environment as possible.
This way, the same compounding effects which inflate the negative impacts of late defect detection work in favour of increasing software quality and resilience.
Knowing the problem is only half the equation. The practical answer lies in two disciplines that directly address everything broken about the traditional model: Shift Left Testing and Continuous Testing.
Shift Left And Continuous Testing
In the next post, I'll break down exactly what both mean in practice, not the buzzword definitions, but how to actually implement them in a real team environment, with real constraints and real delivery pressure.
Because understanding why the traditional model fails is step one. Knowing what to replace it with is where the real work begins.
References & Further Reading
