Does the cost of changing a requirement really rise exponentially with project phase?

## The mechanism that is real Strip the folklore away and a defensible claim remains: **the later a wrong assumption is found, the more work already depends on it.** That dependent work is what you pay to change. When a requirement is wrong at the moment it is written, the cost is an edit to a sentence. When the same requirement is wrong after eleven weeks of building, the things resting on it may include a persistence shape, several interfaces, the automated checks that assert the wrong behaviour, the operator documentation, the training a support team already received, an integration another party has coded against, and — on a fixed-scope engagement — a signed schedule that now needs renegotiating. None of that is mysterious. It is **fan-out**: cost scales with the number of committed decisions downstream of the mistake, and time is a proxy for that number because commitments accumulate. That is why the argument is usually right in practice and why it is worth making. It is also why it is not exponential in any measured, universal sense. ## What the famous curve actually came from The steeply rising curve that gets drawn on whiteboards originates in early defect-cost figures gathered from large, sequential, often defence- and aerospace-scale programmes decades ago. Two separate problems attach to it: 1. **The measurements themselves are contested.** Later analyses have questioned how the underlying data was collected, how phases were attributed, and whether the reported cost ratios were ever reproducible outside the programmes that produced them. 2. **The generalisation is a bigger leap than the data.** Even taking the original figures at face value, they describe programmes with big-bang integration, manual verification and heavyweight change control. Reading them as a property of software itself smuggles in a delivery model as if it were physics. The interview-safe position is to say exactly that: the direction is well supported, the specific multipliers are not something you would assert, and anyone quoting a precise ratio is quoting folklore. Naming a figure you cannot defend is the trap in this question, not the curve. ## What sets the slope The useful reframing is that the slope is an **engineering property of your setup**, not a constant. Two teams building the same product can sit on very different curves. | Steepens the curve | Flattens the curve | |---|---| | One big integration at the end | Continuous integration of every change | | Manual regression checking | Automated checks that run in minutes | | One signed baseline, formal change control | Re-planning as routine, at short intervals | | Tight coupling across the whole codebase | Modular boundaries with narrow interfaces | | Long approval chains before any rework starts | The team can act on a discovery the same day | | Documentation duplicated across many artefacts | A single place each fact is stated | | Long-lead external commitments made early | Reversible commitments deferred until needed | Every entry in the right-hand column is a deliberate investment. That is the honest version of the agile argument: iterative delivery does not repeal the cost of late change, it **spends money up front to flatten the curve**, and it finds the changes earlier so that less is riding on each one. ## Where the curve stays steep no matter what you do Some costs resist flattening, and a strong answer names them rather than pretending everything is cheap to change late: - **Physical and long-lead commitments.** Hardware already fabricated, printed material, an installation window booked with a third party. - **Published interfaces other parties have built against.** Once someone external depends on the shape, changing it is a coordination problem, not a code change. - **Data already collected in the wrong shape.** Migration cost grows with the volume and age of the data. - **Regulatory or safety evidence already assembled.** Re-establishing an approval can dwarf the code change that triggered it. - **Decisions embedded in a contract.** The cheapest technical change can still be an expensive commercial one. ## How to answer this in an interview - Affirm the mechanism first — dependent work, fan-out — so it is clear you are not dismissing the idea. - Say plainly that the exponential curve and its multipliers are contested and that you would not quote a number. - Move immediately to what you control: batch size, integration frequency, automated checking, modularity, approval latency. - Name the categories where the cost genuinely does stay steep, which shows you are not selling the flat curve as universal. That sequence — real mechanism, contested numbers, controllable slope, honest exceptions — is what separates a candidate repeating a slide from one who has thought about it.