Where 70% of the lifetime cost lives — and how to make the case for spending earlier to spend less overall.
| § | Topic | Minutes |
|---|---|---|
| I. | The defect-cost curve | 15 |
| II. | The ROI of quality investment | 20 |
| III. | Maintenance share of TCO | 15 |
| IV. | Technical debt — financial model | 20 |
| — | Discussion: debt audit | 10 |
| V. | Maintain / re-engineer / rewrite | 20 |
| HW10, questions | 10 |
| Phase introduced ↓ · Phase fixed → | Requirements | Design | Code | Test | Production |
|---|---|---|---|---|---|
| Requirements | 1× | 3× | 5–10× | 10–20× | 50–200× |
| Design | 1× | 2–5× | 5–10× | 25–100× | |
| Code | 1× | 2–4× | 10–25× |
A requirements bug found in production costs 50–200× what it would have cost to fix at requirements time. This curve is the single strongest argument for review, prototyping, and continuous validation.
A team finds 50 defects/quarter. Average production-fix cost: $1,500. Adding 20 hours of structured review/week at $80/hr = $6,400/quarter, deflecting ~40% of defects.
| Item | Per quarter |
|---|---|
| Review cost added | −$6,400 |
| Defects shifted left (20 × ~$1,400 saved each) | +$28,000 |
| Net saving | +$21,600 |
| ROI | 337% |
An ROI of 337% on review is not unusual. Yet review is among the first practices cut under schedule pressure — a familiar economic mistake.
Software maintenance breaks into four flavours (Lientz & Swanson):
| Type | What it is | Share of maintenance |
|---|---|---|
| Corrective | Fixing defects discovered post-launch | ~21% |
| Adaptive | Adapting to changes in environment (OS, deps) | ~25% |
| Perfective | Enhancements driven by user feedback | ~50% |
| Preventive | Refactoring, modernisation, testing additions | ~4% |
Perfective is the majority — most maintenance dollars buy features, not fixes. If you measure your maintenance budget by defect count alone, you are measuring 21% of it.
Treat a shortcut as a loan: you ship faster (principal), but pay interest every period you live with the shortcut.
Effort to fix the shortcut now — the "loan amount." Estimate it like a small refactor project.
Extra effort per period that the shortcut imposes (slower changes, more bugs, harder onboarding).
Example: a tangled module costs 8 PD/year of extra effort (interest). Refactoring it would take 30 PD (principal). Refactor "pays back" in 30 ÷ 8 = 3.75 years.
Refactor when discounted interest savings exceed principal. Don't refactor sleeping debt — only debt that's actively earning interest.
| Type | Description | What to do |
|---|---|---|
| Reckless / deliberate | "We don't have time for design" | Stop, regroup |
| Reckless / inadvertent | "What's layering?" | Train, mentor |
| Prudent / deliberate | "We must ship now and refactor later" | Calendar the refactor |
| Prudent / inadvertent | "Now we know how we should have designed it" | Refactor in next iteration |
"Prudent / deliberate" debt is the only one with positive expected value. The other three are technical or organisational failures wearing financial clothes.
In pairs (4 minutes), estimate one piece each: principal, annual interest, payback period.
Three alternatives, all sharing the same horizon and discount rate:
| Option | One-time cost | Annual cost | Risk |
|---|---|---|---|
| Maintain | None | High & rising | Low — known |
| Re-engineer (refactor in place) | Medium | Falling | Medium — partial |
| Rewrite from scratch | Very high | Low (initially) | High — unknown |
Rewrites have a famously high failure rate (Joel Spolsky's "Things You Should Never Do" warning). Compute NPV of all three; apply a risk multiplier to the rewrite case (e.g., 50% probability of completing on plan).
If a rewrite still wins after a sober risk-adjusted NPV, do it. If it only wins on a hopeful base-case, don't.
Replace the system incrementally: build new functionality alongside the old, redirect traffic gradually, retire pieces of the legacy as they become unused.
Economic appeal: lower upfront cost than a rewrite, lower risk than maintenance-forever, optionality at every step (you can stop at any time and still be ahead).
In NPV terms, the strangler captures most of the rewrite's benefit at a fraction of the rewrite's risk-adjusted cost. It's why it's the default in modern legacy modernisation.
Dr. Zhijiang Chen
Software Engineering Economics · Summer 2026
frostburg-state-university.github.io/bju