Not all debt is worth repaying, and the messiest code is rarely the most expensive. A prioritisation framework built on interest rate, change frequency, blast radius, and remaining life — so the argument stops being about taste.
Technical DebtArchitectureStrategy
Share
The four things that decide whether debt is worth paying down
The models here are other people's — Ward Cunningham's debt metaphor, Martin Fowler's quadrant, Adam Tornhill's hotspot analysis — each credited where it appears. What follows every one of them is how I use it when the list is longer than the budget.
The original metaphor
Interest and Principal
"A mortgage you took deliberately, not a mess you made by accident"
Ward Cunningham coined the metaphor in a 1992 experience report and sharpened it in a 2009 talk: shipping something you know is not quite right, in order to learn faster, is borrowing. The interest is the extra effort every subsequent change costs while the loan stands. The principal is the one-off cost of putting it right. Cunningham was explicit that the metaphor never covered writing bad code and calling it a loan — you cannot borrow against work you never chose to defer.
The distinction changes who you are arguing with. Principal is a project: scoped, estimated, fundable. Interest is a tax on everything else you deliver and it never appears on a plan. Teams pitch the principal — 'a three-week refactor' — and lose, because a sponsor can see three weeks and cannot see the tax.
The original metaphor
Interest and Principal
"A mortgage you took deliberately, not a mess you made by accident"
Ward Cunningham coined the metaphor in a 1992 experience report and sharpened it in a 2009 talk: shipping something you know is not quite right, in order to learn faster, is borrowing. The interest is the extra effort every subsequent change costs while the loan stands. The principal is the one-off cost of putting it right. Cunningham was explicit that the metaphor never covered writing bad code and calling it a loan — you cannot borrow against work you never chose to defer.
The distinction changes who you are arguing with. Principal is a project: scoped, estimated, fundable. Interest is a tax on everything else you deliver and it never appears on a plan. Teams pitch the principal — 'a three-week refactor' — and lose, because a sponsor can see three weeks and cannot see the tax.
Four kinds, one decision
Fowler's Technical Debt Quadrant
"There is a difference between a mortgage and a payday loan"
Martin Fowler's 2009 quadrant splits debt on two axes: deliberate or inadvertent, prudent or reckless. Deliberate-prudent is a genuine decision — ship now, pay later, consequences understood. Deliberate-reckless is 'we do not have time for design'. Inadvertent-prudent is the debt you can only see once you understand the domain, and is largely unavoidable. Inadvertent-reckless is not knowing there was a better way. Only one of the four is a decision; the other three are outcomes.
The quadrant earns its keep in a retrospective rather than a planning session. Ask which quadrant a piece of debt came from and you learn something about the organisation instead of the code — deliberate-reckless debt is a schedule problem, inadvertent-reckless debt is a skills problem, and neither is fixed by a refactor.
Where change meets complexity
Change Frequency × Complexity
"Fix the pothole on the road everyone drives, not the one on the closed lane"
Adam Tornhill's behavioural code analysis ranks debt by overlaying version-control history onto code complexity: a hotspot is code that is both complicated and frequently changed. The point is that complexity alone costs nothing — interest is only charged when somebody has to touch the code. The evidence already sits in your repository, and it is more honest than opinion because it records what the team did rather than what it complains about.
This is the cheapest way to end a debt argument. Rank the codebase by change frequency, cross it with whatever complexity proxy you trust, and the top ten files are usually not the ones anyone was campaigning about. Everybody's least-favourite module is often the one nobody has touched in two years.
What breaks when this breaks
Blast Radius
"A leaking pipe in the basement is not the same as one in the shed"
Interest measures what debt costs to live with. Blast radius measures what it costs when it fails. A tightly-coupled component that a dozen services depend on carries a different risk profile from an isolated one with identical internal mess. The practical proxies are coupling, shared state, and the number of teams that must coordinate before anything can change — the last of which is usually the one that shows up in delivery dates.
Blast radius is what converts a debt item into a risk item, and risk gets funded where engineering quality does not. The same remediation loses as 'improving code quality' and wins as 'removing a single point of failure four teams depend on'. Same work, different sponsor, different answer.
The payoff test
Carrying Cost vs Remaining Life
"Do not reroof a house you are demolishing next year"
The decision is a comparison rather than a judgement: interest per month, multiplied by how long the system will realistically live, set against the cost of remediation. Debt in a platform due for decommissioning is debt you should keep paying interest on. Debt in a system that will carry the business for another decade compounds until not fixing it becomes the expensive option. Neither answer depends on how ugly the code is.
Making the comparison explicit is what moves a debt conversation from taste to arithmetic. Estimate the interest badly if you must — hours lost per change, incidents per quarter, days added to onboarding — but estimate it. A rough number somebody can argue with beats a strong opinion nobody can.
The list has to be credible
Not All Mess Is Debt
"An ugly cupboard nobody opens is not a maintenance problem"
Code that is unpleasant, unfashionable, or written to an older standard is not debt if nobody needs to change it, because debt is defined by the interest it charges and untouched code charges none. The reverse is less comfortable and equally true: clean, modern, well-tested code in a component that changes daily can still be the most expensive thing you own, if the design underneath it is wrong.
A meaningful share of every technical-debt backlog I have seen is aesthetic — code that offended whoever read it last and has been stable for years. Closing those tickets is not neglect. It is what makes the remaining list short enough, and credible enough, to actually get funded.
From complaint to portfolio
Most organisations sit on the second rung: everything is logged, nothing is ranked, and the loudest engineer sets the agenda.
Debt management maturity
The right-hand label is what the debt list is actually worth at each rung
Hours per change, incidents per quarter — rough, but written down
Visible
Ranked on hotspots and blast radius
Version-control evidence rather than the loudest voice
Ranked
Standing capacity, tracked to a delivery metric
A fixed share of every cycle, measured on lead time and change failure rate
Compounding
A standing capacity allocation only works above the ranking rung. Applied to an ungroomed list it funds whatever is loudest, and then gets cut at the first delivery squeeze because nobody can show what it bought.
Decision framework
Frequently asked questions
What is technical debt?
Ward Cunningham coined the metaphor in a 1992 experience report and clarified it in a 2009 talk: shipping something you know is not quite right, in order to learn faster, is borrowing. The interest is the extra effort every subsequent change costs while the loan stands; the principal is the one-off cost of putting it right. He was explicit that it never meant writing bad code and calling it a loan — you cannot borrow against work you never chose to defer.
How do I decide which technical debt to pay down first?
Four questions, in order. How often does the code change — because debt only charges interest when somebody touches it. Can you state the interest per month in hours, incidents, or onboarding days. How many teams must coordinate to change it, which converts a quality item into a risk item. And how long the system will realistically live, since interest times remaining life is what you compare against the cost of remediation. Nowhere in that list is how the code reads.
What is Fowler's technical debt quadrant?
Martin Fowler's 2009 quadrant splits debt on two axes — deliberate or inadvertent, prudent or reckless. Deliberate-prudent is a real decision: ship now, pay later, consequences understood. Deliberate-reckless is skipping design under schedule pressure. Inadvertent-prudent is debt you can only see once you understand the domain, and is largely unavoidable. Inadvertent-reckless is not knowing there was a better way. It is most useful in a retrospective, because each quadrant points at a different organisational fix rather than a refactor.
How do I make the business case for paying down debt?
Argue the interest, not the principal. Principal is a project a sponsor can see and decline; interest is a tax on everything else you deliver, and it never appears on a plan. Put a rough number on it — hours lost per change, incidents per quarter, days added to onboarding — and where the debt is heavily coupled, reframe it as risk. The same remediation loses as "improving code quality" and wins as "removing a single point of failure four teams depend on".
Should we allocate a fixed percentage of capacity to technical debt?
Eventually, yes — but only once the list is ranked. A standing allocation applied to an ungroomed backlog funds whatever is loudest, produces nothing anyone can point at, and gets cut at the first delivery squeeze. Earn the allocation by ranking on hotspots and blast radius first, then tie it to a delivery metric such as lead time or change failure rate, so the spend has evidence attached when the squeeze arrives.
Is all messy code technical debt?
No. Debt is defined by the interest it charges, and code nobody needs to change charges none — so an unpleasant module that has been stable for years is not a debt item, however much it offends the last person who read it. The reverse is less comfortable: clean, modern, well-tested code in a component that changes daily can be the most expensive thing you own if the design underneath it is wrong. Closing the aesthetic tickets is what makes the remaining list credible enough to fund.