The Boehm Cost of Change Curve: What the 1981 Data Actually Shows

Updated May 2026. Primary source: Boehm, Software Engineering Economics (Prentice-Hall, 1981). Revision: Boehm and Basili, IEEE Computer, January 2001.

The original 1981 data

Boehm's 1981 dataset captured defect-fix cost across the standard waterfall phases (requirements, design, code, development testing, acceptance testing, operations) on 63 large software projects. The headline finding was that the cost of fixing a defect rises roughly an order of magnitude per phase. A defect introduced in requirements and caught in requirements cost roughly $1; the same defect caught in design cost $5 to $10; in code, $10 to $20; in development testing, $50 to $100; in acceptance testing, $100 to $200; in operations, $200 to $1,000.

The exact ratios varied widely by project. The headline 1:10:100 simplification (heuristically: $1 to prevent, $10 to detect in development, $100 in production) was a downstream popularisation, often attributed to the IBM Systems Sciences Institute. Boehm's original curve was always presented with confidence intervals and project-type breakdowns; the loss of that nuance in subsequent citations is one of the more common misuses of the data.

Note: the 2001 columns are reconstructed from Boehm and Basili's IEEE Computer article and from subsequent ASRM (Annual Software Risk Management) survey data. The point of the comparison is the slope difference, not the precise numbers.

The 2001 revision

In the January 2001 issue of IEEE Computer, Boehm and Victor Basili published Software Defect Reduction Top 10 List, a short article that ranked the most-supported empirical findings about software defect economics. The article explicitly revisited the cost-of-change curve and noted that for small, agile, CI/CD-equipped projects, the slope is meaningfully flatter than the 1981 data suggested.

The mechanism is straightforward. The 1981 cost premium for late detection was driven by the cost of returning to an earlier phase, re-doing affected design or specification work, and coordinating the change across a large, structured team. In a CI/CD environment where defects are caught minutes after code is committed, the cost of returning to design is much lower because the design context is still in the developer's head and the affected code is small. The slope flattens because the cost gradient between phases is smaller, not because defects become free to fix late.

Crucially, the 2001 revision did not reverse the directionality. Late defects still cost more than early defects. The Top 10 list reaffirmed that early defect prevention is the highest-leverage software engineering investment, and the underlying finding survived the move from waterfall to agile. The poor-testing root-cause page covers the modern shift-left interpretation of the same principle.

The IBM SSI multipliers

The IBM Systems Sciences Institute is the most frequently cited secondary source for the 1-10-100 ratio. The IBM SSI work in the 1980s and 1990s reported defect-cost multipliers consistent with the Boehm 1981 data, often presented as cleaner round numbers (1:10:100 instead of Boehm's ranges). The IBM SSI methodology has been criticised for limited sample size and weak documentation, but the ratios it reports are within the range of subsequent academic work.

The most honest position is that the 1-10-100 rule is a useful heuristic that is supported (in direction, if not in exact magnitude) by the underlying Boehm data, the IBM SSI work, the NIST Planning Report 02-3 (2002), and decades of subsequent industrial measurement. Citing the rule without acknowledging the heuristic nature of the specific multipliers is the most common rhetorical sin in the cost-of-quality literature. This page exists partly to provide a careful version of the citation.

How to use the curve in decisions

The curve is a directional argument, not a precise prediction. Three legitimate uses, in order of strength:

1. Justifying shift-left testing investment. The curve provides the foundational evidence that catching defects early is cheaper than catching them late. Use it to defend the cost of pre-commit static analysis, unit-test maintenance, threat modelling for new features handling sensitive data, and accessibility audits performed at design phase.
2. Justifying design review discipline. The same curve supports investing in architecture decision records (ADRs), design docs that get reviewed before code starts, and three-amigos sessions before sprint planning. The most expensive defects are spec or design defects that are not caught until production.
3. Justifying CI/CD investment. Boehm and Basili's 2001 revision is explicit: strong CI/CD flattens the cost-of-change slope, which means more defects can be caught cheaply in development. The cicdcost sister site covers this argument in detail.

Where the curve is misused: as a precise dollar prediction for any specific project (it is not designed to do that), as universal apologetics for waterfall (Boehm's own 2001 work walks this back), and as a substitute for measured COPQ on your own team (the curve is a starting heuristic; your team's actual numbers are the goal). The COPQ calculator is the natural next step once you accept the curve's directional argument.

Sources

• Boehm, B. Software Engineering Economics. Prentice-Hall, 1981.
• Boehm, B. and Basili, V. Software Defect Reduction Top 10 List. IEEE Computer, January 2001.
• IBM Systems Sciences Institute. Relative Costs of Fixing Defects. IBM, mid-1990s working papers.
• NIST. Planning Report 02-3: The Economic Impacts of Inadequate Infrastructure for Software Testing. RTI International, 2002.
• Capers Jones / Namcook Analytics. Software Defect Origins and Removal Methods. Multiple editions.

Frequently asked questions