Types of technical debt, and which ones to worry about

A new technical lead joins, spends two weeks reading, and reports that the website "has a lot of technical debt". The owner nods. Then comes the harder question: so what do we do first? The answer is usually a list of forty items in no particular order, and the conversation stalls.

It stalls because "technical debt" is being used for several different things at once. Some of it was a sensible trade. Some is an accident. Some is dangerous and some will never matter. Sorting it is the first step to doing anything about it.

Four kinds, by how the debt was taken on

Martin Fowler's quadrant sorts debt by two questions. Did the team know it was borrowing? And was the decision prudent or reckless?

• Deliberate and prudent. "We ship the simple version now and deal with the consequences after launch." A known trade with a reason.
• Deliberate and reckless. "We have no time for design." The team knows better and skips it anyway.
• Inadvertent and prudent. "Now we know how we should have built it." Nobody did anything wrong; the understanding came later.
• Inadvertent and reckless. The team did not know what good practice was, and does not know what it owes.

This sorting tells you how the debt will behave. Deliberate debt is usually written down somewhere and has edges. Inadvertent debt has to be discovered, which is why an outside review finds things a team cannot see. If the idea of debt itself is new, start with technical debt explained.

Six kinds, by where the debt sits

The second sorting is more practical for a website or web application: where in the system is it?

1. Platform debt. The content system, framework or language version is behind. Often the cheapest to describe and the most urgent, because security fixes stop.
2. Dependency debt. Plugins, libraries and outside services that are abandoned, duplicated or no longer needed.
3. Code debt. Copy-and-paste, special cases and parts nobody understands. What developers usually mean by the term.
4. Architecture debt. The way the parts are joined makes change hard: one database used by everything, a page builder that every page depends on.
5. Test and release debt. No automatic checks, changes made by hand on the live site, no way to go back.
6. Knowledge debt. Nothing is written down and one person holds it all. Invisible until that person leaves.

A seventh is worth naming for sites that depend on search: content and address debt. Old pages nobody owns, redirect chains, duplicate addresses. It does not slow developers. It slows the site's performance in search, and it becomes expensive at the moment of a rebuild.

Which ones to worry about

Not all debt needs repaying. Fowler makes the point that prudent debt in a part of the system that is rarely touched may not be worth paying down, because the interest is small. Three questions sort a list quickly.

• How often is this part touched? Debt in the checkout matters more than debt in a page changed once a year.
• What happens if it fails? An unsupported platform is a security question, not a convenience one.
• Is it growing? A missing test costs the same next year. An abandoned plugin gets worse every month.

In practice this puts platform and dependency debt first, knowledge debt second because it is cheap to reduce, and code tidiness last unless it sits in a part the business changes every week. Putting figures on these is covered in measuring technical debt.

A worked example

Take an invented case: a membership site with forty items on its debt list. Sorted by the two schemes, the list looks different.

Five items are platform and dependency debt, two of them with security consequences. Three are knowledge debt: the payment set-up, the deployment steps and the hosting account exist only in one contractor's head. Twenty-five are code debt, and twenty of those are in an events section used twice a year. The remainder is content debt: four hundred old pages, of which thirty bring visitors.

The forty items become a short plan. Fix the two security items now. Have the contractor write three documents this month. Leave the events section alone. Deal with the old pages as part of the next rebuild, not before. Most of the list needs no action, which is the useful finding.

What to do next

• Take the list you have and mark each item with where it sits, using the six kinds above.
• For each, answer the three questions: how often touched, what if it fails, is it growing.
• Act on what scores on all three. Write down, and consciously leave, the rest.

When platform or architecture debt dominates the list, repair may no longer be the cheaper route. That is the judgement our website modernization assessment is built to make.

Sources

• Martin Fowler, Technical Debt Quadrant, 2009.