Martin Fowler's Technical Debt Quadrant, Extended With Real Examples
Updated 17 April 2026
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.
Deliberate + Prudent
"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
How to Tell Which Cell Your Debt Lives In
Ask two questions about any piece of debt you are considering:
AXIS 1
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 2
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.
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.