The Cost-of-Change Curve
Here is one of the most important ideas in all of software, and it's simple: the later you catch a problem, the more it costs to fix. A misunderstanding caught while planning costs a five-minute conversation. The exact same misunderstanding caught after launch can cost a frantic fix, an apology to users, and real money.
Plotted across the phases from the last topic, the cost of fixing a mistake doesn't rise gently — it climbs steeply, roughly multiplying at each stage. That shape is called the cost-of-change curve, and once you've seen it you can't unsee it.
Think of a typo. In a draft, you fix it for free. Catch it at the proofreading stage, still cheap. But catch it after the book is printed and shipped to ten thousand stores, and now you're reprinting and recalling. Same typo, wildly different cost — entirely because of when it was found.
The Curve
The exact numbers vary by study and project, but the pattern is remarkably consistent: each phase a mistake survives into makes it several times more expensive to fix. The illustration below uses round, made-up figures — don't take them literally, take the shape.
| Caught during… | Relative cost to fix |
|---|---|
| Requirements | 1× |
| Design | ~5× |
| Build | ~10× |
| Testing | ~15× |
| Production (after launch) | ~100× |
Why It Rises So Steeply
The reason is straightforward: the later you are, the more has been built on top of the mistake. Fix a misunderstanding in the requirements and you edit a sentence. Fix it after the code is written, tested, and shipped, and you have to change the code, re-test it, re-release it, possibly fix the data it already corrupted, and deal with the users it already affected. The mistake didn't grow — the pile of work resting on it did.
The Payoff of Catching Early
This single curve is the business case for nearly every practice in this course. Clear requirements, design reviews, code reviews, automated tests — they can feel like overhead that slows you down. The curve is why they pay for themselves: they're cheap ways to catch mistakes early, on the flat left side, instead of expensively on the steep right side. Spending an hour to prevent a production incident is one of the best trades in software.
"Shift Left"
Because earlier is cheaper, the whole industry has a phrase for the strategy: shift left. Picture the phases laid out left to right, planning on the left and production on the right. "Shifting left" means moving your checks — testing, security reviews, quality gates — as far toward the planning end as you can, so problems are found before they're expensive. You'll meet the phrase again in the testing and security chapters; this curve is why it exists.
Cadence makes it vivid. Suppose the team misreads a requirement about when a streak resets. Caught at Priya's story review, it's a quick edit to one sentence. Caught after launch, it's a hotfix shipped under pressure, an apology email, and — worst of all — users who lost streaks they'd earned, and some trust along with them. Same mistake; the only variable is when it was found.
- "It's cheaper to fix bugs in production, where I can actually see them happening." Seeing a bug live doesn't make it cheap to fix — it's the most expensive place to fix it. Easy to observe, costly to repair.
- "Skipping planning and design saves time." It front-loads speed and back-loads cost. The time you save up front is usually repaid many times over in expensive late fixes.
- "The curve is only about bugs." It applies to any change — a misunderstood feature, a wrong assumption, a design that won't scale. Anything caught late is dearer to change.
- This one curve justifies almost every upfront practice in the course — requirements, design, review, testing — in a single picture. Keep it in mind and they all make sense.
- It reframes "slowing down to do it right" as actually the faster path, because it avoids the steep right-hand side of the curve.
- "Shift left" is a phrase you'll hear constantly on real teams; this is the idea underneath it.
Knowledge Check
What does the cost-of-change curve describe?
- Fixing a problem gets steeply more expensive the later it's caught
- Fixing a problem gets cheaper the later it's caught
- The cost to fix a problem stays exactly the same no matter which phase it is caught in
- How quickly the finished software runs for users
Why does fixing a problem get more expensive in later phases?
- By then more has been built on top of the mistake, so fixing it touches much more
- The mistake itself physically grows larger over time
- Developers deliberately charge more money for their work in the later phases of a project
- Computers run more slowly toward the end of a project
What does "shift left" mean?
- Moving checks like testing and reviews earlier in the lifecycle, where fixes are cheap
- Pushing testing as late as possible, just before release
- Aligning the app's user interface and all of its buttons to the left-hand side of the screen
- Moving the whole team to a different office
A teammate argues it's fine to skip design review because "we'll catch any problems in testing." How does the curve respond?
- Catching it in design is much cheaper than catching it later in testing or production
- The curve agrees — reviews are a waste since testing catches everything
- Testing always catches every possible problem, so design review is pointless
- The curve stays completely neutral and has nothing at all to say about when to review designs
You got correct