What’s all the fuss about?

Before considering ways to deal with technical debt it’s worth looking at why it’s bad and why engineers make such a fuss about it. Technical debt gets its name because it’s an analogy with real debt, which is accrued when something is borrowed. Our original definition chimes in nicely with this analogy. Doing something the quick way is like debt because you will have to pay it back later when you redo the feature the right way.

Time is wasted

For our more precise definition things are not so clear. This is because the essence of the analogy lies in a different aspect of debt — interest. When a codebase has high levels of technical debt every time an engineer is working on it they waste time trying to understand code or work around poorly defined behaviours. This wasted time is an interest payment and this is where technical debt gets it’s name from.

Estimates are less reliable

With real debt interest rates are often fixed, well understood and applied on a regular basis. This enables individuals to plan around their debt and empowers them to borrow responsibly to buy a car, house or something else that they couldn’t realistically save for. Technical debtors lack this luxury. It can be very difficult to predict when an engineer will stumble on some nasty code and lose time dealing with it. There are ways of identifying bad code but even then it’s not easy to work out just how much time is going to be lost. This means that estimates become less reliable.

It gets worse

The analogy goes further though. Like real debt, technical debt can easily spiral out of control. If an engineer has 8 hours to implement a feature but spends 6 dealing with technical debt they are going to be tempted to prefer an expedient solution to a maintainable one which increases the level of technical debt still further.

It’s boring and frustrating

A common pejorative term among software engineers is “big ball of mud” which refers to a code base that is riddled with technical debt. Hacking round technical debt is not much fun. Engineers want to build things and they don’t like being impeded or being wrong about their estimates. If it’s taking twice as long as it should to deliver functionality engineers don’t feel like they are making progress and become frustrated. Technical debt annoys engineers greatly and often they would rather find a new job than put up with it for an extended period of time. This can lead to a destructive churn cycle, where waves of engineers come into a team, estimate based on previous experience, hit the mud, have to hack in more messy code to meet the estimates, get fed up and then leave the solution in an even worse state to the previous people.