Technical Debt Quadrant
Classify debt as deliberate or inadvertent, and prudent or reckless; each needs a different response.
“So the useful distinction isn't between debt or non-debt, but between prudent and reckless debt.”
To an executive
Not all shortcuts are equal. Some are sensible bets made knowingly, others come from carelessness, and each calls for a different response and a different conversation.
To an engineer
Label debt as deliberate or inadvertent, prudent or reckless. Repay the prudent kind when its cost bites, and treat the reckless kind as a signal to fix habits.
The idea
Fowler extended Ward Cunningham's debt metaphor with two axes: was the debt deliberate or inadvertent, and was it prudent or reckless? That gives four kinds:
- Deliberate and prudent: “we must ship now and will deal with the consequences.”
- Deliberate and reckless: “we don't have time for design.”
- Inadvertent and reckless: “what's layering?”
- Inadvertent and prudent: “now we know how we should have done it.”
Fowler argued the last quadrant is unavoidable, because building a system is how a team learns what its design should have been. It signals a healthy team rather than a failure.
Why it works
Debt is not one thing. Lumping every shortcut together makes the conversation about blame or about time. Splitting it by intent and judgement points to different causes.
Different causes need different fixes. Reckless debt is usually a skills, standards or culture problem; more schedule will not fix it. Prudent, deliberate debt is a business trade-off that needs a repayment plan. Prudent, inadvertent debt is learning, and the fix is refactoring as understanding grows.
It makes debt discussable with non-engineers. The quadrant gives stakeholders a way to see which debt was a sensible bet and which was avoidable.
Where it applies
- Debt registers and reviews, to sort items and look for patterns.
- Retrospectives, to talk about why debt appeared without turning it into blame.
- Conversations with product owners about whether to take on a deliberate shortcut.
- Hiring and training plans, when much of the debt turns out to be inadvertent and reckless.
How to apply
- List the significant debt items, with a rough cost of carrying each.
- Place each in a quadrant, honestly, based on what the team knew at the time.
- Look at the distribution, especially where the expensive items cluster.
- Choose remedies by quadrant: repayment plans for deliberate debt, skills and review for reckless debt, routine refactoring for learning.
Example scenario
A team's debt review produced 40 items and a request for a "debt sprint". The architect asked them to place each item in the quadrant before deciding anything.
Most of the expensive items turned out to be inadvertent and reckless: code written without understanding the layering the platform expected. That pointed to a training and code-review gap rather than a schedule problem, so alongside the cleanup the team added design pairing and stricter reviews, and the rate of new debt dropped.
Questions to ask
- Did we take this debt on knowingly, or did we only discover it later?
- Given what we knew at the time, was it a sensible trade-off?
- Where do most of our expensive items sit, and what does that say about the cause?
When not to use it
- Small, local cleanups, where classifying the debt takes longer than fixing it.
- Throwaway code, where the debt will be discarded with the system.
How it misleads you
Using the quadrant to assign blame. It is a diagnostic for choosing remedies. Hindsight also pushes items towards "reckless"; judge each decision by what the team could reasonably have known then.
Further reading
Last reviewed · Suggest an improvement