# Technical Debt Prioritisation Source: John Bradshaw — https://bradshaw.cloud URL: https://bradshaw.cloud/strategy/technical-debt/ Type: insight Tags: Technical Debt, Architecture, Strategy > 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. ## 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. ### Interest and Principal _The original metaphor_ **Analogy:** 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. **Business take:** 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. ### Fowler's Technical Debt Quadrant _Four kinds, one decision_ **Analogy:** 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. **Business take:** 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. ### Change Frequency × Complexity _Where change meets complexity_ **Analogy:** 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. **Business take:** 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. ### Blast Radius _What breaks when this breaks_ **Analogy:** 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. **Business take:** 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. ### Carrying Cost vs Remaining Life _The payoff test_ **Analogy:** 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. **Business take:** 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. ### Not All Mess Is Debt _The list has to be credible_ **Analogy:** 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. **Business take:** 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 - Debt lives in engineers' heads — Known only to whoever last got burnt by it — Invisible - A backlog labelled "tech debt" — Everything logged, nothing groomed, nothing scheduled — Noise - Each item has an owner and an interest estimate — 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 ### How often does this code actually change? **Rarely → it is charging you no interest. Leave it and close the ticket.** Debt only costs you when somebody touches it. Rank by change frequency from version control before anything else — the repository records what the team did, which is a better guide than what it complains about. Stable, ugly, unloved code is the cheapest thing you own. ### Can you state the interest per month? **No → you have a complaint, not a business case. Estimate it badly rather than not at all.** Hours lost per change, incidents per quarter, days added to onboarding — any of them will do. Teams pitch the principal ("a three-week refactor") and lose, because a sponsor can see three weeks and cannot see the tax. A rough number somebody can argue with beats a strong opinion nobody can. ### How many teams must coordinate to change this? **More than two → it is a risk item, not a quality item. Fund it as one.** Blast radius measures what the debt costs when it fails, not what it costs to live with. 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. ### How long will this system realistically live? **Shorter than the payback → keep paying the interest. Do not reroof a house you are demolishing.** Compare interest per month times remaining life against the cost of remediation. Debt in a platform due for decommissioning is debt you should carry. Debt in a system that will run the business for another decade compounds until not fixing it becomes the expensive option. ## 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. ## Diagrams Standalone SVG diagrams, licensed CC BY 4.0 with attribution to John Bradshaw — link back to https://bradshaw.cloud/strategy/technical-debt/ when embedding. - [Interest and Principal (SVG)](https://bradshaw.cloud/strategy/technical-debt/diagrams/interest-and-principal.svg) - [Fowler's Technical Debt Quadrant (SVG)](https://bradshaw.cloud/strategy/technical-debt/diagrams/quadrant.svg) - [Change Frequency × Complexity (SVG)](https://bradshaw.cloud/strategy/technical-debt/diagrams/hotspots.svg) - [Blast Radius (SVG)](https://bradshaw.cloud/strategy/technical-debt/diagrams/blast-radius.svg) - [Carrying Cost vs Remaining Life (SVG)](https://bradshaw.cloud/strategy/technical-debt/diagrams/carrying-cost.svg) - [Not All Mess Is Debt (SVG)](https://bradshaw.cloud/strategy/technical-debt/diagrams/not-debt.svg) ## Interactive companion **Technical Debt: Rank a Backlog** — Score each backlog item on interest rate, change frequency, blast radius and remaining life, and rank the list by what is actually worth repaying. Interest and frequency multiply, so debt in code nobody touches sinks to the bottom where it belongs. Live calculator: https://bradshaw.cloud/strategy/technical-debt/calculator/ ## Related - [Technical debt portfolio scorecard](https://bradshaw.cloud/writing/technical-debt-portfolio-scorecard/) — the practical template for turning a backlog into a funded decision. - [Team Topology Decisions](https://bradshaw.cloud/strategy/team-topologies/) — the boundaries that decide where debt accumulates. - [Build vs Buy](https://bradshaw.cloud/strategy/build-vs-buy/) — the same total-cost thinking, applied before the code exists. - [Platform Operating Model](https://bradshaw.cloud/strategy/platform-operating-model/) — where undifferentiated debt gets absorbed once, not repaid per team. - [FinOps Maturity](https://bradshaw.cloud/strategy/finops-maturity/) — the same carrying-cost discipline applied to infrastructure spend. - [The WyCash Portfolio Management System](https://c2.com/doc/oopsla92.html) — Ward Cunningham’s OOPSLA ’92 experience report, where the debt metaphor first appears. - [TechnicalDebtQuadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html) — Martin Fowler’s deliberate/inadvertent × prudent/reckless split. - [Your Code as a Crime Scene](https://pragprog.com/titles/atcrime2/your-code-as-a-crime-scene-second-edition/) — Adam Tornhill on behavioural code analysis and hotspots. - [All strategy insights](https://bradshaw.cloud/strategy/)