# Cost of changing software late: what the data shows > Does fixing late cost 100 times more? Across 171 projects the effect did not show up consistently. Our reading: the cost depends on where the rule lives. - Author: Marlon Trettin - Published: 2026-10-28 · Updated: 2026-10-28 - Language: en - Canonical: https://yowpi.com/en/blog/cost-of-changing-software-late-what-the-data-shows --- Does fixing late cost dozens of times more? Not always. The rule comes from 1981 curves whose underlying data was never published, and a study of 171 projects did not find the effect consistently. A more useful hypothesis: the cost of changing depends on where the decision lives in the system. ## TL;DR - The rule that fixing cost grows dozens of times by the final phases comes from 1981 curves whose original data points were never published. - Across 171 projects from 2006 to 2014, the effort to fix a late problem stayed close to the effort of fixing it early in most phase pairs. The largest medians fell between 2.5 and 3 times. - The study measures defects in teams with a disciplined process, not scope changes requested by the business. It does not prove that late change is cheap. - Our reading, which the data does not test: for a buyer, the useful question is how many places a rule lives in the system. ## Where does the rule that late change costs 100 times more come from? One origin is Barry Boehm, who in 1981 published cost curves by project phase. According to [Tim Menzies and coauthors](https://arxiv.org/abs/1609.04886), one of them shows a 40-fold increase up to acceptance testing, and another a 100-fold increase for larger projects before delivery. The same account records that the data points behind those curves were never published, and that Boehm reported, in 1980, a flatter curve for small projects. The idea spread. According to [Steve McConnell](https://stevemcconnell.com/articles/an-ounce-of-prevention/), Boehm and Philip Papaccio estimated in 1988 that a requirements defect that reaches the field can cost 50 to 200 times more to fix than one caught near where it originated. Menzies and coauthors also cite ratios of 1 to 137 at Toshiba and 1 to 117 at IBM, reported by workshop participants, again without raw data. None of this is made up, and the idea that a problem gets more expensive the later it is found is intuitive. The point is that it circulates as a fixed number, and the study below treats it as a hypothesis to test. ## What did a study of 171 projects find? It found little evidence of the effect. Tim Menzies, William Nichols, Forrest Shull and Lucas Layman analyzed 171 software projects run between 2006 and 2014, from 45 organizations in 6 countries, all recorded in a Team Software Process (TSP) database. They compared the effort to fix a problem in the phase where it originated with the effort to fix it in later phases. The result, published on arXiv, is that the medians of those ratios stayed close to 1 in most pairs. The largest were 3.0, between planning and unit test, and 2.54, between requirements and integration test. At the 90th percentile, the largest value was also 3.0. Almost all comparisons did not differ significantly. The authors conclude there is no consistent or substantial evidence of the effect and suggest it may be a historical relic, present only intermittently in certain kinds of projects. ## What does this study not prove? It does not prove that changing a system late is cheap. First, every project used TSP, a disciplined process developed by the employer of two of the authors. A project without that kind of process is not what this sample portrays. Second, the study measures the effort to fix defects. It does not measure what the company loses while it waits, nor a scope change requested by the business after the system is live, which is the case that matters most to a buyer. And the authors themselves acknowledge that they had no control group to compare TSP against other processes. What remains is more modest: the multiplier is not a constant. In some projects the cost grows over time and in others it does not, and the question becomes what explains the difference. ## What makes the cost of change vary? The data does not answer that, and what follows is our reading. One starting point is a [1972 paper by David Parnas](https://doi.org/10.1145/361598.361623) in *Communications of the ACM*. Parnas proposes that a system should not be divided starting from a flowchart, but from a list of difficult design decisions or decisions likely to change, with each module hiding one of them from the rest. In the example he analyzes, the decomposition he defends confines a change in how data is stored to a single module. In the conventional one, the same change requires altering all of them. Translated to how a company operates: the cost of changing a rule depends on how many places it was written in. When the rule lives in one spot, changing it is one edit. When it is scattered, each copy is a chance to forget one, and the error shows up weeks later, far from where it started. That is an architecture problem, not a technology problem: the tool matters less than where the company's decisions live. ## A practical example: an insurance broker's commission rule The scenario is hypothetical, with no measured numbers. An insurance brokerage with 40 people changes the commission rule for one line of business. In the first system design, the rule appears in the calculation spreadsheet, on a registration screen, in a report and in the integration with finance. Changing it means finding all four places. If one is missed, the discrepancy only shows up at month-end close, when the difference has already become manual reconciliation. In the second design, the rule is a table with an effective date, read by every screen and integration. The same change becomes a new row with a start date. The business request is identical, and the cost of changing depends much less on the project phase in which the request arrived. What separates the two designs was decided at the start, when someone asked where the rule should live. ## How do you use this when buying a system? In three short steps, before approving the scope. The first is to list the five decisions most likely to change in the next 12 months: commission rule, price table, registration fields, approval limits, what each role can see. The second is to ask whoever will build it, in writing, in how many places each of those decisions will exist. The honest answer for several will be "one", and for some it will be "two or three, and here is why". The third is to test before delivery. Ask for one of those rules to be changed in the prototype and watch how many screens or integrations have to be touched. It is a cheap way to see the cost of change before paying for it. The article on [what an approved prototype still needs to become a system](/en/blog/prototype-approved-what-makes-it-a-system) covers that handoff, and the piece on [why software quotes come back so far apart](/en/blog/why-software-quotes-come-back-so-far-apart) helps compare proposals that answer this question differently. Systems keep changing after delivery. In the [Colo Saúde case](/en/cases/colo-saude), Yowpi took over an inherited platform and cut its consumption of the original platform's capacity by 60%, a figure from the published case, and its evolution continued with the same team. It is an example of a system that kept evolving after it was finished, not proof of the effect described in the study. ## Frequently asked questions **Integration with what I already use will be complicated. Does that make later change more expensive?** It can, because every integration is a place where a rule may be copied. The question from the second step applies here too: which data leaves the new system for the ones you already use, and which of them is the source of each rule. In our reading, an integration where only one side defines the rule tends to be cheaper to change than two that repeat it. **I don't have a qualified team to implement this. How do I judge a vendor's answer?** Ask for the answer in writing and compare across proposals. Someone who understands your operation answers with names of rules and places, such as "the commission lives in the effective-date table and the screens only read it". A generic answer about "flexible architecture" does not say in how many places a change will land. **I'm not sure the return justifies it. Should I freeze the scope so I don't pay for change?** Freezing the scope is a reading the study does not support. It does not say that change is always cheap. It says the cost depends on the project. Instead of freezing, separate what is stable from what is likely to change and give the latter a single home. That way the scope can grow without every new request touching everything. ## The next step If every rule change in your system today turns into a hunt for the places where it is written, the Operational Architecture Diagnostic, a 30-minute working session, serves to map where each decision lives before you plan the next change: [schedule the diagnostic](/en/contact).