A non-technical description of technical debt

In software engineering, “technical debt” is a feature of an application’s code which makes future changes more difficult.

Technical debt takes many forms, but it can be as simple as methods with misleading names, outdated documentation or large sections of repeated code.

As an analogy, imagine that an indicator bulb fails on the dashboard of your car. You buy a new bulb and, pop out to replace the old one. Your spouse warns you that dinner will be ready soon. “Don’t worry,” you say, “it’s only a ten minute job”.

When you climb into the driver’s seat however, you can’t find any way to open the dashboard; in fact there are no screws visible at all. So you open the bonnet and look for suitable screws there. The screen wash reservoir is in the way, so you carefully remove that, but due to the way the pipe is connected, this means spilling all the washer fluid on the ground. Your spouse calls that your dinner is on the table. “Nearly there.” you reply. Now you can see some screws which look like they might release the dashboard, but they’re completely inaccessible. The only way is to get the engine out, so you replace the screen wash reservoir and drive the car around to a friend who has an engine-lifting winch. Luckily it comes out without any nasty surprises and you undo a screw labelled “DB release” – simple!

Inside the car however, the dashboard is not at all released and you notice one of the wipers is hanging loose. You re-attach the wiper and locate the correct screws. Finally, the dashboard opens! But it’s not over yet – the bulb you bought, after consulting the car manual, doesn’t fit. As the car is still in bits you take a taxi to the car dealer who supplies you with the correct bulb. When you vent your frustrations, he explains that the bulb you had was for an earlier model and when the new car was designed they weren’t given time to update the manual. Apparently the dashboard is made of a single piece of solid plastic because that makes manufacturing easier and cheaper. No one ever checked the screws were labelled correctly as the release date was brought forward to compete with a car from another manufacturer. Maintenance costs are usually down to the end user and rarely feature in reviews…

So eventually you get the bulb replaced, the engine back in and take the car home. By now your dinner is not just cold, it has things growing on it and your spouse is threatening divorce.

The car in my analogy has terrible technical debt. The “interest payments” needed to modify or fix it are huge. But in other ways it might still be a good car – good handling and fuel consumption and it’s black, everyone likes black. To anyone who has never opened the bonnet, the car is fine – it works, so what’s the problem?

If the occasional hassle of changing a bulb doesn’t seem like a big deal, bear in mind that software is changed a lot. No sooner is an application released than new features are needed, bugs may be discovered or perhaps an external system changes that requires the application to change to keep up. A code file is created once, but will likely be changed hundreds or thousands of times over the lifetime of the application. Most of these changes are not anticipated from the outset and the cost of making them can be dramatically affected by how well-designed, well-documented and testable the code is.

Sometimes code is made well in the first place – that takes an upfront investment of time. Sometimes existing code is improved to be more maintainable – the time to improve it is like paying off the debt. In either case the investment saves time down the line.

There is more on writing maintainable software here. For a deeper look at technical debt, read Martin Fowler’s piece.