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. Kruchten, Nord, and Ozkaya (2012) extended it with a seven-category taxonomy (code, design, architecture, test, documentation, infrastructure, build debt). Each category 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 Kruchten's seven-category taxonomy.
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.