Measuring technical debt without reading the code

A finance director asks a fair question in a budget meeting: how much technical debt do we have? The development lead answers with a tool's output. Four hundred and twelve days of debt, rated C. The director writes the number down, and nobody in the room knows whether it is a reason to spend money or not.

The number is real, in the sense that a tool produced it. It is not useful, because it measures the code and the question was about the business. Debt can be measured in terms that support a decision, and most of the measures need no access to the code at all.

Why a single score misleads

Code analysis tools count things they can see: repeated code, long functions, missing tests, known weaknesses. They convert the count into an estimate of repair time. That is worth having, and developers should use it.

It misleads as a headline figure for three reasons. It counts debt in a part nobody touches the same as debt in the checkout. It cannot see an outdated platform, an abandoned plugin or a process that lives in one person's head, which are often the largest items. And it measures the principal, the cost of repair, when the decision depends on the interest: what the debt costs you every month you keep it. The difference between the two is explained in technical debt explained.

Five measures you can ask for

Each of these can be collected from records the team already has. None needs a new tool.

1. Time for a standard change. Pick a small, common request, such as a new field on a form. How long from request to live, now and a year ago? A rising figure with the same team is interest, measured directly.
2. Faults per release. Of the last ten releases, how many needed a fix afterwards? This shows whether changes in one place break another.
3. Versions behind. For the platform and each major dependency: the version in use, the current version, and whether the one in use still receives security fixes.
4. Parts nobody will touch. Ask the team to list them. Then ask how often the business needs changes there. Avoided parts that the business needs are the expensive kind.
5. People who can release. How many people can put a change live, alone, without calling someone? If the answer is one, that is debt, and the cheapest kind to fix.

Reading the measures together

One measure proves little. The pattern across them tells you which kind of problem you have. The kinds are described in types of technical debt.

• Versions far behind, everything else steady: platform debt. A defined piece of work, getting more urgent as support ends.
• Change time and faults both rising: the structure is the problem. Repairs will help less each time.
• Few people can release, parts avoided: knowledge debt. Solved by writing things down and sharing the work, not by rebuilding.
• All five poor: the cost of staying is high enough that replacing the system should be costed properly.

Then turn the pattern into money, roughly. If a standard change takes three times as long as it did, two thirds of what you pay for such changes is interest. Set a year of that beside the estimate for the repair. You will not get a precise figure. You will get one good enough to rank the options, which is what the budget meeting needed.

A worked example

Take an invented case: a booking site for a chain of clinics. The tool says three hundred days of debt. The five measures say something more specific.

A standard change takes nine working days, up from three. Four of the last ten releases needed a follow-up fix. The platform is two major versions behind and security fixes for it end within the year. The team avoids the appointment calendar, which the business wants to change every month. Two people can release.

The reading: the calendar is where the interest is paid, and the platform sets a deadline. The other two hundred and fifty days of counted debt are in reporting screens that work and rarely change. The decision narrows to one question, whether to repair the calendar on the current platform or rebuild it as the first stage of moving off it. That choice is covered in when rewriting a legacy application is the wrong call.

What to do next

• Ask for the five measures this week. Accept rough answers.
• Repeat them each quarter. The direction matters more than the level.
• Use the tool's score inside the team, and the five measures in the budget meeting.

If the measures point to the platform or the structure, the next step is a baseline of the whole site before anything is changed. Our website modernization assessment starts there; the sample assessment shows what a baseline looks like.

Sources

• Martin Fowler, Technical Debt, 2019.