Technical debt: how to measure it and get time to pay it down

Why "we need a refactoring sprint" keeps losing

A lead asks for two weeks to "clean up the billing module". The product director asks what the company gets for those two weeks. The lead says "fewer bugs, faster work later". The sprint goes to a feature. Six months later the same module eats a release, and the same conversation repeats with worse numbers.

My position: technical debt is a business argument that engineers keep making with engineering words. You win time for it when you can show where it sits, what it costs per month and what you will measure after paying it down. This article is for leads and architects who have to make that case: four ways to measure debt, how to turn them into hours and money, three budgeting models, and a checklist to run before you ask.

First, which debt are you talking about

Martin Fowler's technical debt quadrant, published in 2009, splits debt along two axes: deliberate or inadvertent, prudent or reckless. It is useful less as a theory than as a sorting tool for the backlog.

Only the first and last rows deserve a budget conversation. The middle two are process problems, and paying them down without changing the process just refills the backlog.

Four signals that measure debt

No single number describes debt. I use four, from cheapest to collect to most convincing.

1. 1

   Static analysis debt ratio

   SonarQube estimates remediation effort for every maintainability issue and divides it by the cost to write the code, assuming 30 minutes per line by default. A ratio up to 5% rates A, 5 to 10% B, 10 to 20% C, 20 to 50% D, above 50% E. It is a quick baseline. Its limit: it counts rule violations everywhere, including code nobody has touched in three years.

2. 2

   Churn times complexity: hot spots

   Adam Tornhill's method, built into CodeScene: take how often each file changes from Git history and cross it with how hard the code is to work with. In one CodeScene example, prioritised hot spots were about 1.2% of the codebase but took 12.5% of development effort and held about 45% of the fixed bugs. Debt in a file that never changes costs nothing. Debt in a file changed every week is a monthly bill.

3. 3

   Lead time for changes, per module

   The DORA metric, measured per service or module instead of for the whole company: time from commit to production. If changes to the billing module take 9 days and the rest of the code takes 2, that gap is the debt expressed in calendar time.

4. 4

   Change failure in hot spots

   The share of deployments touching a module that need a rollback or hotfix. This is the number a product director understands without translation: "one in four releases that touch this code breaks something".

The research behind signal 2 is worth quoting to the business. Tornhill and Borg studied 39 proprietary codebases and 30,737 files in 2022: low-quality code had 15 times more defects, issues in it took on average 124% longer to resolve, and the worst-case cycle times were 9 times longer. That last figure matters most to a product team, because unpredictability is what breaks roadmaps.

Turning debt into hours and money

The business does not buy "code health". It buys hours back, fewer incidents and dates it can trust. The conversion is simple arithmetic, and doing it badly is still better than not doing it.

The example figures in the table are illustrative; use your own from Git, the tracker and the incident log. For a sense of scale, Stripe's Developer Coefficient survey from September 2018 asked developers and executives how much time goes to maintenance: the mean was 17.3 hours a week, against an average work week of 41.1 hours. Your team will differ. The survey is a sanity check, not your baseline.

Then promise one number back. "After four weeks on checkout, lead time for its changes drops from 9 days to under 4, and hotfixes from 6 a month to 2." If you cannot name the number, the business is right to say no.

Three ways to budget the time

I have not found a credible source for the "always spend 20%" rule that circulates in talks, so treat the share as a choice you make and revisit, not a law.

Most teams I would advise end up with a mix: a small fixed share for everyday cleanup, cleanup attached to features, and a targeted project once or twice a year where the data points at one place. The fixed share is the one to protect in writing, with the product owner's name on it.

One page for the business

The pitch that works fits on one page and has five lines. Where: the module and its share of incidents or changes. Cost now: hours and money per month from the table above. Ask: weeks of whose time. Result: the one metric and its target. Check date: when you will report back, even if the result is bad.

Leave out the debt ratio unless someone asks. A product director who hears "rating C" learns nothing; one who hears "1 in 4 releases touching checkout needs a hotfix" asks when you can start. This kind of trade-off reasoning is also what staff and principal interviews probe, and a practice round on a pair mock interview is a cheap place to rehearse it out loud.

Before you ask for a debt sprint

If you ticked fewer than three, spend a week collecting data before the meeting. A weaker case presented twice is worse than a strong one presented once.

The short version

Sort debt by Fowler's quadrant and only budget for the prudent kind. Measure it with hot spots, lead time per module and change failure; keep the static debt ratio as a baseline, not an argument. Translate it into hours and money, promise one metric back, and choose the budget model that fits where the debt sits.

Related: do AI coding assistants make teams faster, system design theory: 12 concepts, when your manager will not promote you.