The quality dilemma and the cost of quality

The dilemma is real, not a moral failing

Ship something of terrible quality and nobody buys it. Spend without limit chasing perfection and you miss the market window or exhaust the budget — and nobody buys that either, because it does not exist. Every organisation therefore aims at a middle band: good enough not to be rejected on evaluation, not so polished that it never ships. Pretending this dilemma away is what makes exam answers about quality sound naive. The engineering question is not should we want quality but where does the next hour of quality effort buy the most, and answering that requires knowing what quality costs and what the lack of it costs.

"Good enough" — when it works, when it is negligence

Good enough software delivers the high-value functions well while knowingly shipping more obscure or specialised functions with known bugs, on the bet that most users will forgive the second set because they are happy with the first. Large vendors with a marketing budget do this every day and improve in v2.0. Three conditions decide whether you may: market position — a small company that ships a buggy v1.0 may never get to sell v2.0, because reputation is the only asset it has; domain — for embedded, automotive, avionics, medical or any system integrated with hardware, shipping known defects moves from commercial judgement to negligence and, in some jurisdictions, criminal liability; and explicit criteria — a team that cannot state what "good enough" means for this product has not made a decision, it has just run out of time.

The cost of quality has three buckets

The cost of quality is every cost incurred pursuing quality plus the downstream costs of not having it. It divides into three.

• Prevention — planning and coordinating the quality-control and quality-assurance work, the additional technical effort to produce complete requirements and design models, test planning, and the training that makes all of it possible.
• Appraisal — the cost of finding out what condition the product is in the first time through each activity: technical reviews, data collection and metric evaluation, testing and debugging.
• Failure — costs that would vanish if no errors ever escaped, split in two. Internal failure is detected before shipment: rework, the side effects that rework itself introduces, and the cost of collecting the data that tells you how the work failed. External failure is detected after shipment: complaint handling, returns and replacement, help-line support, warranty labour — and the loss of reputation, which is genuinely hard to quantify and therefore routinely, and wrongly, excluded from the arithmetic.

The arithmetic that ends the argument

The order of the buckets is also the order of their unit cost. Industry data collected consistently over decades shows the cost of finding and correcting one problem rising by roughly an order of magnitude as it moves from requirements to design to code to system test to post-release maintenance. That escalation is why prevention and appraisal look expensive on a sprint budget and cheap on a product budget, and it is why the first thing to cut under schedule pressure — reviews — is precisely the thing whose removal costs the most later.

Worked example — one BorrowBox defect, priced four ways

BorrowBox's late-fee rule rounds each daily charge up to the nearest ten pence before summing, instead of after. It is one line. Caught in the requirements review, it is a wording fix to an acceptance criterion: about an hour, and it is a prevention/appraisal cost. Caught in integration testing, it is a code change, a new test and a re-run of the fee suite: most of a day, an internal failure cost. Caught after release, it has overcharged 340 members by a few pence each: a support queue, a refund run, a finance reconciliation, an apology, and a librarian who no longer trusts the numbers on her screen — a week of work and a reputational cost the team cannot put a number on. Same defect, same line of code; the only variable is when it was found.