The cost of changing your mind depends on two things: how fast feedback arrives, and how much got…
Two cases, three shaky sources, and the two things that actually decide the cost of changing your mind
The cost of changing your mind depends on two things: how fast feedback arrives, and how much got built on the decision first.
Two cases, three shaky sources, and the two things that actually decide the cost of changing your mind
Washington, DC
Plan more up front and the project goes better. The advice shows up in postmortems, project courses, and consulting decks, usually next to the same exhibits: a project that skipped planning and blew up, a NASA chart, and a cost-of-change curve. I went looking for the sources. The chart failed to replicate. The curve’s citation trail collapses under inspection, and its own author flattened it twenty years later. The disasters are real, but they teach something narrower and more useful than the advice hung on them.
Denver, and its software twin
Denver opened its new airport with a fully automated baggage system: 17 miles of track, 4,000 radio-controlled carts, and thousands of scanners, budgeted at $238 million. The airport opened sixteen months late in February 1995, and the baggage system was the reason. The delay ran around $33 million a month, roughly $500 million by opening day, with $271 million in bond interest in 1994 alone. The GAO documented it while the terminal sat empty.
Three decisions before construction did the damage. Munich had built a smaller system and needed two years plus six months of round-the-clock testing, and Munich’s team warned Denver that the compressed schedule would fail. Denver put the work out to bid, three firms responded, none could meet the timeline, so the city rejected all three and talked a fourth, BAE, into trying anyway. And the airlines who would run the system were left out of early design; when finally consulted they demanded ski racks, oversized-baggage handling, and separate maintenance tracks, forcing redesign of finished work. Denver later spent about $51 million on a manual backup. The automated system was abandoned in 2005.
The FBI ran the same play in software. Its Virtual Case File burned about $170 million from 2000 to 2005, roughly $105 million of it on unusable code, after the bureau started building with no agreed architecture and cycled through fifteen key IT managers, per the Justice Department Inspector General. The replacement, Sentinel, nearly failed the same way, then recovered once the FBI took it in-house in 2010, cut requirements, and shipped iteratively. A project that recovered by planning less complicates the moral.
The three sources, examined
Gruhl’s chart. Werner Gruhl, of NASA’s cost analysis branch, plotted the share of budget spent on early definition work against eventual overrun. Projects spending under 5 percent overran 80 to 200 percent; projects spending 10 to 15 percent came in near budget. Textbooks reproduce it as settled, some prescribing “spend a tenth on planning.” The National Academies checked it in 2010 and reported that three of their primary references found little or no correlation between early-phase spending and cost growth. The relationship failed to appear when other analysts looked at overlapping missions.
Boehm’s curve. Barry Boehm published the cost-to-fix curve in 1981, from defect data at TRW, IBM, and GTE: a bug caught during requirements costs little, the same bug caught after delivery up to a hundred times more. IBM later popularized the 1:10:100 shorthand for defect repair, which gets conflated with requirements change constantly. Laurent Bossavit traced the citation chain in The Leprechauns of Software Engineering and found it leads back to data too thin to carry the claim, each textbook citing the last rather than the source.
The 1981 number was probably right for 1981. Boehm’s projects were large defense and embedded systems. A late change meant reprinting paper specs, rerunning manual tests over weeks, shipping physical media to installations, and the loop between writing a requirement and watching it run was measured in months. The hundredfold premium described that world accurately.
The two things that actually matter
Drop the disputed multipliers, and something usable is left. The steepness of the curve depends on two things: how long feedback takes to arrive, and how much has been built on top of a decision before anyone questions it. Neither is fixed. An organization sets both, mostly without noticing.
Denver shows both at their worst. The feedback that mattered, Munich’s warning and the airlines’ needs, arrived only after track was welded, a delay measured in years. And the city piled everything onto its earliest choices: a fixed date, one integrated design, a terminal that could not open without the system. The FBI did the same in software, stacking 700,000 lines on requirements nobody had settled. Sentinel recovered by cutting both at once, shrinking each commitment and checking it in months.
This is also where the planning-versus-iteration argument dissolves. Questions are nearly free while a project is drawings and conversations, and the same questions cost tens of millions once concrete sets against them. Planning answers them before anything gets built on top. Small batches keep what gets built small enough to pull back out. Both work the second variable from opposite ends, which is why pitting them against each other misses the point of either.
The curve got flatter as the world sped up
Kent Beck put the curve’s collapse at the center of a method. The 1999 Extreme Programming Explained names a flattened change-cost curve as the technical premise of XP: once late change stops being ruinous, the practices built to prevent it stop earning their keep.
Boehm conceded much of it. Writing with Victor Basili in 2001, he put the post-delivery multiplier near 100 for large, high-dependability systems but around 5 for small, iterative ones. The gap between those numbers is not the decade. It is the distance between a decision and its feedback.
Then the largest direct test. Menzies, Nichols, Shull, and Layman studied issue-resolution effort across 171 commercial projects from 2006 to 2014 and, in a 2017 paper, found no delayed-issue effect: fixing something late did not reliably cost more than fixing it early. They also found the belief widespread, and one reviewer checked four undergraduate textbooks and found the old exponential curve still taught in all of them.
Fifty years of tooling reads as one long assault on the first variable. The 1970s maximized feedback distance; everything after 1981 cut it, until the multiplier that measured it stopped showing up in the data.
The AI era finishes the job
Code generation is approaching free. A model writes in minutes what took days, and revising costs another few minutes. Whatever premium was left on typing has collapsed.
That kills the first variable for anything that is only code, and the second variable is what remains, because the costs that survive were never about typing. Changing a published interface still costs, since every consumer built against it, and with enough users every behavior has a consumer whether the contract named it or not. Changing a data schema still costs, in the records and the migration. A defect in production still costs revenue and trust. A decision other teams organized around still costs a reorganization. Code-change cost fell toward zero; commitment-change cost never moved.
Cheap generation adds a cost the 1981 curve never priced. Volume. When a change costs nothing to produce, changes multiply, and each still needs a person or a harness to confirm it works. The scarce resource shifts from building to checking. An organization that adopts generation without growing its capacity to verify is mass-producing the exact late-caught defects the old curve priced at a hundred.
The response follows from the split. Spend almost no deliberation on anything that is only code, since building it three ways and throwing two away now beats a meeting about which way to build it. Give the full weight of the old advice to commitments, a public interface, a data model, a platform choice: decide them late and carefully, and put them behind versioned interfaces so even a one-way door gets a hinge. Move the planning effort the cheap side no longer needs into verification, machine-checkable acceptance criteria, fast test harnesses, and review capacity treated as the real constraint. Some decisions are expensive to unwind. The work is knowing which ones.
What this leaves for a manager
None of this argues for slower delivery. Speed carries real weight, and Jeff Bezos put the case in his 2016 letter to Amazon shareholders: make most decisions at about 70 percent of the information you wish you had, since waiting for 90 usually means moving too slowly, and for a team good at catching and reversing bad calls, being wrong is cheaper than being slow. His 2015 letter drew the dividing line. One-way doors, irreversible and consequential, get made slowly and carefully. Two-way doors get walked through fast, because a wrong choice reverses. A door is one-way exactly to the degree that things get built on top of it, so his rule and the second variable are the same test.
The letters and the disasters describe one discipline from two ends. Speed pays only while course correction stays cheap, and cheap course correction is what fifty years of flattening the curve bought. Denver moved fast on one-way doors: a fixed date, one design, concrete against both. The FBI wrote 700,000 lines against unsettled requirements. Neither failed from speed. Both failed from spending speed on the irreversible while the reversible questions went unasked.
So the claim is plausible, the disasters back it, and it is far less proven than its confidence suggests. It is no reason to slow everything down. Sort the doors first. Answer the cheap questions before the expensive commitment. Hear out the team that has built one before, while the schedule can still move. Keep each commitment small enough that being wrong costs weeks, since the one correction the data does support, Boehm’s own, is that late change gets cheap when feedback comes fast. Then move at whatever speed the reversible work allows, which is most of the work.
Denver needed none of these citations. It needed to hear Munich out, and to ask the airlines what a bag does on its way to a plane, back when both questions were free.
By Joshua McDonald on August 6, 2026.
Exported from Medium on August 26, 2026.
Reader discussion