Boehm's Cost-of-Change Curve: What Is Real and What Is Folklore
The cost to fix a defect or absorb a change rises the later it is caught. That much is real and well sourced. The tidy “1 : 10 : 100” chart everyone copies is not. Here is the difference.
Does a bug really cost 100x more to fix in production?
On large projects, roughly yes. Boehm and Basili's peer-reviewed Software Defect Reduction Top 10 List (IEEE Computer, January 2001) found that fixing a problem after delivery is often about 100 times more expensive than fixing it during requirements and design. But they add the caveat almost everyone drops: on small, non-critical projects the ratio is closer to 5 : 1. The direction is solid; the famous granular chart (1x design, 6.5x coding, 15x testing, 100x maintenance) credited to an “IBM Systems Sciences Institute” study is unsourced folklore that traces to a textbook footnote, not to any real study.
What the cost-of-change curve actually says
The cost-of-change curve is one of two figures Barry Boehm published in Software Engineering Economics (Prentice Hall, 1981). It captures a simple, durable idea: a defect or change is cheap to fix when it is caught close to where it was introduced, and expensive when it is caught later, because everything built on top of it has to be reworked. A wrong requirement fixed while writing requirements costs a conversation; the same wrong requirement fixed after release can mean re-design, re-code, re-test, re-document and a field update.
Two decades later, Boehm and Victor Basili restated the finding in their Software Defect Reduction Top 10 List (IEEE Computer, January 2001). Item number one reads: “Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.” Critically, the same paper notes that for smaller, less critical systems the escalation is closer to 5 : 1 than 100 : 1. The 100x figure is a large-system finding, not a universal constant.
This is why late scope change is one of the most reliable drivers of a budget overrun: the curve means a change agreed in month 18 does not cost the same as the same change in month 2.
The chart everyone copies, and why it is unsourced
Search “cost of fixing a bug” and you will find the same table again and again, usually credited to the “IBM Systems Sciences Institute”:
| Phase defect is caught | Relative cost to fix (as commonly quoted) | Status |
|---|---|---|
| Design | 1x | Unsourced |
| Implementation / coding | 6.5x | Unsourced |
| Testing | 15x | Unsourced |
| Maintenance / production | 60–100x | Unsourced |
These specific multipliers are presented above only to identify the claim. They are widely repeated but not verified — see below.
The problem, documented by Laurent Bossavit in The Leprechauns of Software Engineering and by Hillel Wayne (and covered by The Register in July 2021), is that the “IBM Systems Sciences Institute” study does not exist as published research. The trail runs back to Roger Pressman's textbook Software Engineering: A Practitioner's Approach, which attributed the numbers to internal “IBM81” course notes. The “Institute” was an internal employee-training program, no underlying data set has ever been produced, and any figures are no more recent than 1981 and possibly far older.
So the honest position is a split verdict:
- The direction is real. Multiple independent lines of evidence — Boehm 1981, Boehm & Basili 2001, and the general logic of rework — agree that late fixes cost dramatically more than early ones.
- The precise per-phase multipliers are not. The 1x / 6.5x / 15x / 100x table is folklore dressed as data. Do not cite it as a finding, and be wary of any business case whose numbers depend on it.
If you need a defensible figure, use the sourced one: ~100x after delivery for large systems, ~5:1 for small ones, attributed to Boehm & Basili (2001). This is the same discipline we apply to the “53,000 tech projects, 63%” stat.
Cost-of-change curve vs Cone of Uncertainty
Both figures are attributed to Boehm and both get called “Boehm's curve”, which is why they are constantly confused. They answer different questions:
| Cost-of-change curve | Cone of Uncertainty | |
|---|---|---|
| What it measures | Cost to fix a defect or change | Accuracy of the estimate |
| Shape over the lifecycle | Rises (change gets pricier) | Narrows (estimate gets tighter) |
| Headline figure | Up to ~100x by production | 4x out at concept, ~1.25x by design |
| Use it to | Justify catching problems early | Size early contingency honestly |
For the estimate-accuracy figure see the Cone of Uncertainty.
What to do about it
- Front-load requirements and design. The cheapest defect is the one caught before it is built. This is the same logic behind the NASA requirements-vs-overrun curve.
- Shift testing left. Automated tests, reviews and static analysis move detection earlier, where the curve is flat.
- Price late change explicitly. A change request in late execution is not the same cost as the same change in planning; make the difference visible in the change-control log rather than absorbing it silently.
- Do not build a business case on the 1:10:100 chart. Use the sourced ~100x / ~5:1 range and state which project scale you mean.
Sources
- Boehm B., Basili V. (2001). Software Defect Reduction Top 10 List. IEEE Computer 34(1): 135-137.
- Boehm B. (1981). Software Engineering Economics. Prentice Hall.
- Bossavit L. (2015). The Leprechauns of Software Engineering. Leanpub.
- The Register (22 July 2021). “Everyone cites that bugs are 100x more expensive to fix in production, but the study might not even exist.”