Not all debt is the same problem wearing different clothes. Martin Fowler's 2009 quadrant maps debt across two axes — how it originated (deliberate or inadvertent) and how it was approached (reckless or prudent). Knowing which quadrant you're in changes which remediation strategy actually works.
Fowler's insight was that "technical debt" isn't one thing — it's shorthand for four very different situations that get lumped together. The first axis asks whether the trade-off was made on purpose (deliberate) or discovered later (inadvertent). The second asks whether it was made carelessly (reckless) or thoughtfully, with eyes open (prudent). Cross them and you get four quadrants — and four different playbooks.
"We don't have time for design." The most expensive quadrant — corners cut with no plan to revisit them.
"We must ship now and deal with the consequences." A legitimate strategic trade-off, made on the record.
"What's layering?" Debt from not knowing better — usually a skills or experience gap.
"Now we know how we should have done it." Debt from learning — the least blameworthy, still costly.
A startup commits to shipping an e-commerce platform in six weeks. Under deadline pressure, the team skips service boundaries, duplicates logic across three modules to move faster, and hardcodes configuration values that were meant to be temporary. No one writes down that any of this happened.
Skipped code reviews, copy-pasted logic instead of shared abstractions, hardcoded values standing in for config, and tests that get commented out "for now" and never restored.
Declining team morale, features that take longer each sprint despite a stable team, a rising incident rate, and new hires needing months instead of weeks to become productive.
25–40% of engineering time annually
Dedicated debt sprints to stop the bleeding, then the 20% Rule (see the Payoff Strategies guide) to prevent it from re-accumulating once the backlog is under control.
A payments team ships with a single-region database ahead of a funding-critical launch date. They document the limitation in an architecture decision record, put a feature flag around the riskiest path, and schedule the multi-region migration for the following quarter.
Written ADRs, timeboxed workarounds with an owner and a date, feature flags used deliberately, and MVPs scoped with a known, planned second pass.
This quadrant is healthy as long as the "planned second pass" actually happens. The warning sign isn't the debt itself — it's a documented workaround with no revisit date that quietly becomes permanent.
10–20% of engineering time annually
Treat the 20% Rule as standard operating procedure, not a rescue plan — this is where it works best, because the debt was already scoped and estimated at creation time.
A team of junior developers, new to distributed systems, builds a healthcare data pipeline without understanding idempotency or retry semantics. Network blips during peak load silently drop records for months before anyone notices the gap.
Misapplied design patterns, architectural decisions made without awareness of the failure modes they invite, and security practices skipped not on purpose but because the risk was never visible to the team.
Bugs that "shouldn't be possible" according to the code, data quality issues nobody can trace to a root cause, and a growing gap between what the team believes the system does and what it actually does.
30–50% of engineering time annually
Structured training paired with the Strangler Fig pattern — replace the misunderstood components incrementally, under supervision, rather than attempting a single high-risk rewrite.
A team builds a microservices architecture with eventual consistency, following the best available guidance at the time. Eighteen months in, real usage patterns reveal the domain actually needed strong consistency in one critical path — something no one could have known upfront.
Evolving requirements that invalidate earlier assumptions, technology choices that were reasonable when made but have since been superseded, and design decisions that only look wrong in hindsight.
Recurring workarounds clustered around the same subsystem, and engineers describing a component as "correct but fighting the domain" rather than "broken."
15–30% of engineering time annually
Strangler Fig migration, planned and paced rather than rushed — this debt was earned by learning, so the fix should be treated as a normal part of the system's evolution, not an emergency.
| Quadrant | Awareness | Risk | Typical cost | Remediation difficulty | Strategy |
|---|---|---|---|---|---|
| Deliberate / Reckless | Known, undocumented | High | 25–40% | High | Debt sprint → 20% Rule |
| Deliberate / Prudent | Known, documented | Low (if tracked) | 10–20% | Low | 20% Rule as policy |
| Inadvertent / Reckless | Unknown | Very high | 30–50% | Very high | Training + Strangler Fig |
| Inadvertent / Prudent | Discovered later | Moderate | 15–30% | Moderate | Strangler Fig, paced |
Deliberate/prudent debt is a legitimate business strategy when it's written down, estimated, and scheduled for repayment. Plenty of successful launches happen because a team knowingly deferred the "right" solution. The quadrant that actually threatens a codebase is any debt — of any origin — that goes untracked. Untracked debt of any type compounds the same way: silently, and faster than most teams expect.