Managing technical debt as a routine, not a rescue

Every January the product owner at a car rental firm announces a clean-up quarter. New features will pause, the developers will finally fix the reservation site's foundations, and from April everything will be faster. Every year, in the third week, the sales team needs a corporate rate added before a contract is signed. The clean-up stops. It is announced again the following January.

The firm does not lack will. It has chosen a way of dealing with debt that depends on the business standing still for three months, and no business does.

Why the big clean-up fails

A clean-up project treats debt as a mess to be cleared once. Debt is not like that. It is taken on continuously, some of it for good reasons, and it is paid for continuously. A one-off project also spreads its effort evenly, tidying parts of the system that nobody changes and where the debt was costing nothing.

Martin Fowler's advice is to treat it as people treat money they owe: "pay the principal off gradually". Improving a part of the system each time work passes through it has a useful side effect, in his words: "we spend more time on removing cruft in those areas that we modify frequently". Cruft is his word for the gap between the code as it is and as it should be. Parts that are untidy but stable "can be left alone".

Four habits that keep debt in hand

Managing debt comes down to four habits. None needs a new tool, and all of them can be asked for by someone who does not write code.

1. Record it when it is taken on. When the team takes a shortcut to meet a date, it writes one line: what was skipped, why, and what it will slow down. Debt that is written down has edges. A list like this is also the raw material for sorting, as shown in types of technical debt.
2. Rank it by where the work is. Each quarter, mark the items that sit in parts of the system the business keeps changing. Those are the expensive ones. The reasoning is set out in the cost of technical debt.
3. Repay as part of ordinary work. A change in a marked area includes the repair of what it touches, and the estimate says so. Fowler describes the rule developers use for this: "always leave the code behind in a better state than you found it".
4. Review with the same few measures. Once a quarter, look at the time a standard change takes and the other measures in measuring technical debt. If they are steady or improving, the routine is working.

The third habit is the one that needs your backing. It makes individual estimates a little larger, and the developers need to hear from the person paying that this is wanted.

What only the owner can decide

A team can run the routine. Three decisions in it belong to the business.

• When to borrow. Shipping a simpler version to meet a real date is a fair trade. It should be a decision you were asked about, with the cost stated, not something you find out later.
• What to leave unpaid. Some items on the list will never be worth repairing. Saying so, and striking them off, keeps the list believable.
• When routine is not enough. If the platform itself is out of support, or the measures keep getting worse while the routine is followed, gradual repayment will not catch up. That is a different conversation, about replacing or rebuilding.

A year of the four habits at the car rental firm

Picture a car rental firm; it is invented, its year is typical. This year it drops the clean-up quarter and tries the four habits.

The developers write down what they already know: twenty-three items. Marking them by where the work is leaves six that matter, all in pricing and availability, the two areas sales asks about every month. The other seventeen are in the fleet reports and the staff rota, which have not changed in a year. Nine of those are struck off.

The corporate rate that used to interrupt the clean-up now carries part of it. Its estimate includes untangling the pricing rules it has to touch: seven days where the bare change would have been five. The next pricing request is quoted at three days. By the autumn review a standard pricing change takes half the time it did in January, and two of the six items are gone without a single week in which features stopped.

One item does not yield. The booking engine's platform reaches the end of its support next year, and no amount of tidying changes that. It goes on a separate page, with its date.

Starting the routine this quarter

• Ask the team for the list they already carry in their heads, one line an item. Technical debt, explained sets out what belongs on it.
• Mark what sits where the business keeps asking for changes. Strike off what will never matter.
• Agree that work in the marked areas includes repair, and that estimates will show it.
• Put a quarterly review in the calendar with the same measures each time.

If the review shows the routine losing ground, or the platform has a date on it, the question has moved from managing debt to modernizing the system. Our website modernization assessment is built to answer that question for one site or web application.

Sources

• Martin Fowler, Technical Debt, 2019.
• Martin Fowler, Opportunistic Refactoring, 2011.
• Martin Fowler, Is High Quality Software Worth the Cost?, 2019.