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.”
Related
Frequently Asked Questions
Does fixing a bug really cost 100 times more in production?
On large projects, roughly yes. Boehm and Basili's Software Defect Reduction Top 10 List (IEEE Computer, January 2001) states that 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. But they add an important caveat: on smaller, non-critical projects the cost-escalation factor is more like 5 to 1 than 100 to 1. The 100x figure is a real, sourced finding for large systems, not a universal law. What is NOT well sourced is the granular per-phase chart (1x design, 6.5x implementation, 15x testing, 100x maintenance) usually credited to an 'IBM Systems Sciences Institute' study, which cannot be traced to any published research.
What is Boehm's cost-of-change curve?
It is the observation that the cost to correct a defect or accommodate a change rises the later in the project lifecycle it happens. A requirements error caught while writing requirements is cheap to fix; the same error caught in testing or after release forces rework of everything built on top of it. Barry Boehm published the original data in Software Engineering Economics (Prentice Hall, 1981). It is distinct from Boehm's other well-known figure, the Cone of Uncertainty, which is about estimate accuracy rather than the cost of change.
Is the 'IBM Systems Sciences Institute' 1:10:100 cost chart real?
There is no traceable published study behind it. Researchers Laurent Bossavit (The Leprechauns of Software Engineering) and Hillel Wayne traced the chart back to Roger Pressman's textbook Software Engineering: A Practitioner's Approach, which attributed the numbers to internal 'IBM81' course notes, not to peer-reviewed research. The 'IBM Systems Sciences Institute' was an internal employee training program, and no underlying data set has ever surfaced; any data is no more recent than 1981 and possibly much older. Treat the specific 1x / 6.5x / 15x / 100x multipliers as folklore. The directional claim that late fixes cost far more is well supported; the exact numbers on that chart are not.
How is the cost-of-change curve different from the Cone of Uncertainty?
Both are attributed to Barry Boehm (1981) and both are sometimes loosely called 'Boehm's curve', but they measure different things. The cost-of-change curve is about the cost to fix a defect or change: it rises over the lifecycle. The Cone of Uncertainty is about estimate accuracy: an early estimate can be off by a factor of about 4x in either direction, narrowing to roughly 1.25x by detailed design. One tells you why late change is expensive; the other tells you how wrong your early budget is likely to be.