I’ve recently been asked by a non-technical person “What is technical debt?”. At the time I didn’t have a satisfactory explanation, but a recent incident with an electrical house fire made me think of technical debt in a very practical way.
A friend of mine moved into a one-bedroom apartment a few years ago, right after college. The apartment had a small kitchen and he noticed that it only had a single electrical socket, but it didn’t bother him as he often went out to eat and ordered takeaway and he ate cereal for breakfast.
He figured he only needed to make coffee in the morning so one socket should be enough. Then he bought a toaster to have toast with the coffee in the morning. And also a small fridge to store milk, juice, but mostly beers.
So he went to get a cheap 3 outlet power strip, plugged all three appliances and he was good to go. For a while.
Soon he saw that eating out is expensive and bought a microwave to heat up ready-made meals and save some money.
At this point, an electrician told him that he ought to create a new electrical circuit to correctly handle the needs of the appliances. But that was expensive and he was trying to reduce spending, so he added another power strip instead. The problem was solved for now.
After a while, he had enough of the ready-made meals and decided to buy an electrical hob to cook proper meals. With that, he also bought a bigger fridge for the fresh produce. And both these new appliances were plugged into the second power strip that was connected to the initial power strip.
That’s when problems started happening. Every so often a fuse would blow and he would have to replace it. Until one day when he ran multiple appliances at the same time and an electrical fire started.
Luckily he was able to contain it before it spread to the rest of the house. But still, the costs to repair the damages were significantly higher than what it would have cost to add the new circuit in the first place.
So what does that have to do with technical debt?
If you think about it, software projects often start in the same optimistic manner. We only need this feature to cover this simple use case. Soon the business asks to add another “small functionality” and a “very specific corner case”. At the beginning, the code can handle it.
Then, the business asks to use the feature in a completely different way. At that point, your architect or senior developer might say they need to refactor the code to handle the new cases.
But that takes time and money and the business needs the change “yesterday”. Plus they can’t justify “wasting so much time” on one functionality.
And then of course, some new requirements appear, and then some more. By this time, the code is so complicated that adding any feature causes inexplicable behaviors, breaks in existing functionality, or even loss of performance until one day the application is completely unusable.
At this point, the business would have to choose between a costly and risk-prone refactoring of the entire application, or building a new application. Either of these options being a lot more expensive than it would have cost to clear the technical debt in due course.
