Framework library · Technology management
Technical debt quadrant
Technical debt is the shortcuts and outgrown designs in a system. Each costs extra effort every month (the interest) until someone spends the effort to fix it (the principal). Sorting the items by whether they were deliberate or inadvertent, prudent or reckless, shows how they arose and so how to stop more arriving. Comparing interest with principal shows what to pay down first.
Use it when
- A team says it is slowed by old code, and you need to decide how much capacity to give to fixing it and where.
- The same kind of debt keeps appearing, and you want to find the practice or pressure that creates it.
- You need to explain to non-technical leaders why delivery is slowing, as a cost per month they can weigh against new work.
Avoid it when
- The system will be retired within a year. Keep paying the interest until then and put the effort into the replacement.
- The problem is a fault in service today. Fix it through incident and problem management; debt is about the cost of change.
- Nobody can estimate effort at all. The quadrant explains causes but cannot rank items without interest and principal. Time the team's work for a month first.
How to run it
List the debt items specifically
Each item says what was done and where: "plan and price rules copied into three services", not "messy billing code". One row per item.
Place each item in a quadrant
Deliberate debt was a known trade-off; inadvertent debt was discovered later. Prudent debt was a sensible call at the time; reckless debt was not, whether it was chosen or came from not knowing better.
Estimate the interest
The extra effort the item costs each month: workarounds, slower changes, incidents it causes. Person-days a month is precise enough.
Estimate the principal
The effort to fix it properly, including testing and migration.
Pay down where the payback is short
Principal divided by interest is the number of months a fix takes to pay for itself. Under six months, schedule it now; over eighteen, contain it and stop it growing.
Change the practice behind reckless debt
If most of the interest comes from reckless debt, paying it down will not stop more arriving. Change what caused it: reviews, tests, ownership or the way deadlines are set.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Calling every inconvenient design debt. Debt is measured by the interest it costs, and old code that rarely changes costs little.
- Asking for a quarter to "clean up" with no prices attached. Leaders fund items with a payback, not a general tidy-up.
- Treating prudent, inadvertent debt as a failure. Learning later what the design should have been is a normal cost of building something new.
- Paying down debt in code that is about to be replaced. Check the roadmap before scheduling the work.
Where it comes from
Ward Cunningham introduced the debt metaphor in his OOPSLA '92 experience report, "The WyCash Portfolio Management System" (1992): shipping first-time code is like going into debt, and every minute spent on not-quite-right code counts as interest. Martin Fowler added the quadrant, reckless or prudent against deliberate or inadvertent, in "Technical Debt Quadrant" on his website, 14 October 2009. Source.
Use it with
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.