Reducing technical debt: what the work consists of

The board of a concert venue agrees, at last, to spend money on the ticketing site. The minutes say: "reduce technical debt, two months". The developers are pleased. The general manager has one question nobody answers well: at the end of the two months, what will be different, and how will she know?

She is right to ask. "Reducing technical debt" names an intention. The work itself is one of four quite different things, and each has its own price, its own risk and its own proof that it was done.

What reducing debt means

Technical debt has a principal, the work that was skipped or has fallen due, and interest, the extra time every change costs because of it. Both terms are set out in technical debt explained. Reducing debt means making the principal smaller in a place where interest is being paid.

The second half of that sentence matters as much as the first. Martin Fowler's advice for a part of the system that changes all the time is strict: "areas of high activity need a zero-tolerance attitude to cruft, because the interest payments are cripplingly high". Cruft is his word for the gap between the code as it is and as it should be. A part that never changes can be left as it is. So the first step in reducing debt is choosing where, and the cost of technical debt shows how to find the place where the interest is paid.

Keeping debt down afterwards is a routine, described in managing technical debt. This article is about the repair itself.

Four ways to make it smaller

Every item on a debt list can be dealt with in one of four ways. Ask which one is being proposed for each item, because the answer decides the cost.

• Remove. Delete what is no longer used: old features, forgotten pages, add-ons that were installed for one campaign. It is the cheapest reduction there is, because what is gone needs no upkeep and cannot break.
• Bring up to date. Move the platform and the components it depends on to versions that still receive fixes. The work is well defined, and it has a date attached when support is ending. When the platform is far behind, this grows into a project of its own, covered in legacy application replatforming.
• Contain. Leave a tangled part as it is, and put a clear boundary around it so that new work no longer has to pass through it. The debt is still there. It stops charging interest on everything else.
• Rebuild the part. Replace one section with a clean version that does the same job. The most expensive of the four, and worth it only where the business asks for changes again and again.

The order usually follows the list. Removing comes first because it shrinks everything that follows. Fowler describes what a small repair in the right place buys: on the first feature he would "spend an extra couple of days to remove some of the cruft", and that "may be enough to reduce the interest rate on future enhancements to a single day".

How to tell that it went down

A reduction that cannot be shown is a hope. Each of the four ways leaves evidence a non-technical owner can ask to see.

• After removing: a list of what was deleted, and a shorter list of components than before.
• After bringing up to date: no part left without security fixes, checked as described in measuring technical debt.
• After containing: the next change near that part is quoted without the usual warning attached.
• After rebuilding: a standard change in that part takes less time than it did, measured the same way before and after.

Three things are often presented as debt reduction and are not. A new design on the same platform changes what the site looks like and none of what makes it slow to change. More developers on a tangled system pay the same interest in parallel. And a pause on new features reduces nothing unless one of the four kinds of work is done during it.

Eighteen items at the concert venue, sorted four ways

Here is an invented case: a concert venue. Its ticketing site sells seats, memberships and gift vouchers, and a seating plan for a new season took four weeks to add last year.

The developers bring a list of eighteen items. Sorted by the four ways, it reads differently. Seven are removals: a group-booking form that has taken no bookings in three years, a second gift voucher system left from a previous supplier, five add-ons nobody can explain. Three are updates, one of them with a date, because the payment component stops being supported in the summer. Two are parts to contain: the old membership import, which runs once a year and frightens everyone, gets a boundary and is otherwise left alone. One is a rebuild: the seating plan editor, which every new season passes through.

The remaining five are untidy code in the gift voucher pages, which nobody has asked to change. They are written down and left. The kinds of debt behind a list like this are sorted in types of technical debt.

The two months now have a shape. Removals in the first fortnight, with the list of what went. The payment update next, because of the date. Then the seating plan editor, with one measure agreed in advance: how long the next season's plan takes to add. When the autumn season is set up in six days, the general manager has her answer, in a figure she understands.

Working through your own debt list

• Take the list of debt your team already has and write one of the four words beside each item.
• Do the removals first. Ask for the list of what was deleted.
• For each update, ask for the support date.
• For any rebuild, agree the measure before work starts, and take it before as well as after.

If most of the list turns out to be the platform itself, the work is no longer a set of repairs. It is a move to a current platform, with the site's pages and addresses to protect on the way. Our website modernization work starts with a fixed-scope assessment of what that move would put at risk.

Sources

• Martin Fowler, Technical Debt, 2019.