Martin Fowler's technical debt quadrant, extended with real examples
Every tech-debt page reproduces Fowler's 2x2. Nobody maps real engineering decisions to specific cells with evidence and remediation patterns. This page does. Click a cell to explore the example and response.
Layer 01 / Diagnostic Tool
"We must ship now and deal with the consequences.", Fowler, 2009
What it means
The team knows they are creating debt and believes the trade-off is worth it. They have a plan to repay. This is the only quadrant where debt functions as a legitimate financing decision.
Real-world example
Shipping v1 with manual deployment because the two-week automation build is not worth delaying launch by two weeks. The team creates tickets for the automation work and schedules it in the next quarter. The interest: every manual deployment takes 2 hours and introduces human-error risk.
Remediation pattern
Schedule the cleanup on a roadmap with a real sprint allocation and a deadline. Treat the debt ticket like a critical bug: it should never be indefinitely deferred. If the cleanup keeps sliding, the Deliberate+Prudent debt has silently become Deliberate+Reckless.
Diagnostic signal
ADR exists, cleanup tickets created, team could explain the trade-off if asked
Typical cost
Manageable, interest is defined and controllable
Layer 02 / Self-Assessment
How to tell which cell your debt lives in
Ask two questions about any piece of debt you are considering.
AXIS 01
Deliberate or Inadvertent?
Ask: did any engineer on the team, at the time the decision was made, understand that a better option existed and was being deferred? If yes: Deliberate. If no, the team genuinely did not know a better way, it is Inadvertent.
AXIS 02
Prudent or Reckless?
Ask: was there a clear plan at the time to clean up? For Deliberate debt: was there a ticket, an ADR, a timeline? For Inadvertent debt: when the gap was discovered, was it addressed promptly? If not: Reckless.
Field Note
The quadrant's limitations: what it misses
Fowler's quadrant is a diagnostic tool for intent and process, not a taxonomy of types. Type taxonomies answer a different question: what kind of debt is it (code, design, architecture, test, documentation, infrastructure, build)? Each type can appear in any quadrant.
The quadrant also does not capture regulatory debt, supply-chain debt (dependencies you cannot update because a vendor is slow), or legal-compliance debt (code that worked under GDPR pre-2018 that now violates Article 17). These are real debt categories that follow different remediation patterns.
See the types page for the seven types and where they come from.
Continue Reading
Sources
- Fowler, M. TechnicalDebt bliki. 2003.
- Fowler, M. TechnicalDebtQuadrant bliki. 2009.
- Kruchten, P., Nord, R. L., Ozkaya, I. Technical Debt: From Metaphor to Theory and Practice. IEEE Software, 2012.