An often-cited number in software economics is that a bug costs 100x more to fix in production than in design. This number started as a gut feeling in 1981, and forty years of citation hardened it into a “fact”. By the end of this post you’ll know how this happened, why it is still a useful rule of thumb, and what that means for Static Code Analysis.
Open any project-management deck and you will find a curve: On the left, a tiny bar labelled requirements. On the right, a giant bar labelled production. In between, a slope suggesting that bugs found late are 10x, 100x, sometimes 1000x more expensive than bugs found early. The chart is decades old, instantly familiar, and almost never comes with a citation.
How a guess became a fact
The graph traces back to Barry Boehm’s Software Engineering Economics, 1981. Boehm drew a curve from “code” to “operation”, and the cost-multiplier story took off from there. The real problem, documented in The Leprechauns, is that the curve was Boehm’s guess. He extrapolated from limited project data rather than a controlled measurement. That makes the most-quoted number in software economics closer to a meme than a measurement. It does not make Boehm wrong about the direction of the curve, but the slope is very questionable.
So how did that become common knowledge? Through a textbook information cascade, where each author trusts the crowd instead of the source. A first wave of papers cited Boehm in good faith, as one opinion among several. The next wave saw the citation and treated the number as established. By the third or fourth generation, nobody was checking Boehm anymore.
The result is citation laundering, an unsourced claim that gains the appearance of evidence simply by being repeated in authoritative-looking venues. It is the same mechanism that keeps urban legends alive in newsrooms. Once enough people act as if a number is true, doubting it costs more than repeating it. (If you have ever pasted that chart onto a slide yourself, no judgment, it fooled decades of textbooks too.)
The 100x multiplier is a forty-year-old gut-feel, repeated across citations until it sounded like a measurement.
Why “later” intuitively costs more
The cost of a bug does not grow on its own. Each development stage that it survives, adds a new piece of work that has to be repeated, and that catching it earlier would have skipped.
If you fix a bug while typing, then cost is almost nothing, because the context is already in your head and nobody else is involved. On the other hand, if you let it escape, the bill grows. You commit the change which (hopefully) triggers a CI job. Somebody may do a code review. It travels from author to reviewer to tester. Every handoff pays the tax of a context switch, and if we are being honest, we don’t always remember what we have coded one week ago, and why.
The flow above makes it visible. If you have heard about the Toyota Production System, it is just the seven wastes from a software perspective: waiting on CI, transport across handoffs, the over-processing of one defect through repeated review, and the motion of refreshing your memory that paged out weeks ago. A bug caught late becomes a source of muda. A lot of steps have to be repeated, which is wasted effort that is ideally not necessary (only the green steps in the above process chart create actual value – everything else is just means to an end).
Every stage a bug survives adds more delay, handoffs, and rework, and that accumulation is what makes it costly.
The measured version of the same idea
There is serious evidence for the cost-saving effect of early detection in the NIST 2002 report (watch out, old data from 2002!). NIST estimated that inadequate software-testing infrastructure costs the US economy about $59.5 billion per year. More than a third of that cost could be recovered when teams find defects earlier, closer to where the mistake was made.
That is a survey-based estimate rather than a controlled experiment. But “one third” is far more defensible than “100x cheaper”, because it says earlier detection saves money in aggregate without pretending we know the exact multiplier for your codebase. It also says nothing about which early practice does the saving. Reviews, unit tests, dynamic analysis, fuzzing, Static Analysis, and formal methods all live under the same umbrella.
By NIST’s estimate, earlier detection could recover more than a third of what weak testing costs the US economy each year.
Zooming in on Static Analysis
Static Analysis is the early-detection practice I know best, and how much it catches is not a fixed number. It ranges from a fifth of your bugs to most of them. Which tool you run and when you run it, has the greatest impact on the numbers.
Take which tool first. According to a TUM study, each single analyzer missed 47% to 80% of real-world bugs. However, the researchers didn’t include the most capable commercial tools, so this can be seen as the worst case. A few years ago, I did some experiments with the strongest static analysis tools (based on formal methods), and out of a broader study of 60 real-world CVEs, could find eleven of the fourteen 2018 FreeRTOS CVEs. Hence, we can probably conclude that in practice, Static Analysis is capable of finding between 20% and 80% of memory-safety bugs.
Now when. Facebook’s Infer report saw near-zero fix rates when it dumped warnings into a batch report, and over 70% once the same warnings appeared in code review. The difference is ownership. A warning on the diff you just wrote is unmistakably yours, and a reviewer is watching. The same warning buried in a batch of thousands belongs to no one, and waits for someone else. This is just human nature.
Static Analysis catches anywhere from 20% to 80% of bugs, and developers are more likely to act on them when reported early.
My runway, twice
Early in my career I worked on a flight controller with a weak Static Analysis tool. Bugs surfaced in the field, just before flight testing, with a dozen people on the runway waiting for me to fix things on the spot. You know the particular silence of a runway that is waiting on you. Was that 100x more expensive than catching the same bug in my office? Nobody could say. The exact multiplier needs a counterfactual that does not exist. What I do know is that it was bad, and it was avoidable.
Years later, during my PhD, I worked on a second flight controller with my students, the StratoX high-altitude glider at TUM. This time we used Formal Verification from day one. Coding took more effort, but the verifier caught real defects before any testing took place. One was an off-by-one error in the GPS parser that would otherwise have first met us on the runway. When we finally did go flight testing, there were no surprises on the runway, and we could focus the mission.
The cost for bugs had not disappeared, it had just moved upstream, into hours of careful coding instead of hours of panic on the field. That is the cost-shift story behind every argument for early detection. The effort simply transfers from the worst possible moment to the cheapest one, and saves all the repeated work in between.
Catching a bug early moves its cost to a calmer place, and reduces development iterations.
Summary
The “100x cheaper to fix early” rule is folklore. Boehm’s graph was one researcher’s opinion, and forty years of uncritical citation gave it the shine of common knowledge. But I still like the message behind it, since it leads to good practice. Any process that moves a bug closer to where it was written, transfers the problem to a calmer place and saves cost and time.
The action that you can take is small. Turn on Static Analysis in your IDE or coding agent today. Not in next sprint, not just on your CI system. The marginal cost of fixing a warning while you are still typing is measured in seconds or minutes, instead of days and weeks.