How does the cost of fixing a defect change depending on when in the software lifecycle it is discovered, and what makes the curve so steep?
The later you find it, the more it costs — from x1 in requirements to a mean of about x250 once the system is in operations, which is why rework and bug-fixing can swallow up to half a project's effort.
* The multipliers on a log scale: the range per phase, with the mean joining them up. *
A defect found while the requirements are still being written costs one conversation. The same defect found in production has to be unwound from every decision that was built on top of it — the design that assumed it, the code that implemented it, the tests that certified it, the documentation that described it, and the live data already stored the wrong way. Each of those layers must be changed and re-verified, and each re-verification can itself go wrong. That compounding is what turns a linear delay into an exponential bill:
| Phase at which the error is detected and fixed | Cost to fix |
|---|---|
| Requirements | x1 (reference) |
| Design | x3 to x8 |
| Build | x7 to x16 |
| Test | x21 to x78 |
| Operations | x29 to x1615 (mean x250) |
Money is only the measurable part of the damage. A late security defect can also trigger regulatory consequences — a supervisor can force you to shut the service down until it is fixed — and it can cost reputation, which no amount of money buys back quickly.
Tip: Turn the multiplier around and it becomes a budgeting argument: since reworking and bug-fixing may account for up to 50% of the total effort on a project, time spent nailing the requirements down early is not overhead competing with "real" work — it is the cheapest slot in the whole schedule to spend it in.
Go deeper:
NIST Planning Report 02-3 — The Economic Impacts of Inadequate Infrastructure for Software Testing — the underlying research, with relative repair costs tabulated by the stage a defect is caught.- Shift-left testing (Wikipedia) — the practice this curve is the argument for.