Peter Morlion logo


How Do You Explain Technical Debt?

Are you finding yourself having a hard time explaining technical debt? You might have a good grasp of what technical debt is and why it’s holding you back, but that doesn’t mean your manager fully understands. Let’s look at some ways you can explain things to management.

The Debt Metaphor

Ward Cunningham coined the term “technical debt” as a way to explain the concept of taking shortcuts and having to bear the consequences.

So you can explain technical debt by taking that literally: it’s a debt the team is taking. A certain technical choice is more costly in the long run than a more optimal one, but it provides a short-term win that is worth it. However, stack on too much debt and you can go bankrupt.

When you explain this to someone less technical, you can make things less abstract by explaining that certain ways of implementing will be fast now, but if you do that too much, things will slow down later. Bugs will pop up more. And that’s OK, if we have a plan to pay back our debt, i.e. improve the bad implementation we’re using now.

Long story short: bad implementation now means quick results in the short run but bad results in the long run if nothing is done about it.

One shortcoming of the technical debt metaphor is that if seems to make us focus on cost. And as Rachel Stevens explains clearly, business can live with an increase in cost. That’s because they’re used to taking on debts, as long as it provides a benefit and is predictive. After all, you know how much the monthly payment is for a financial loan.

But things are a little trickier with technical debt.

The Call Option Metaphor

You can compare technical debt to a call option on the financial market. Now I’m not an expert, but this is how I understand it.

A call option is a contract between a buyer and a seller of a financial asset (like bonds or shares). The two parties agree on a price, and the buyer then has the right (not the obligation) to buy the asset after a certain amount of time. The buyer has to pay the seller a certain amount for this right. This is what we call the premium.

If things go well for the buyer, the value of the asset increases, but they can still buy it for the agreed price, which will be lower than the current value. So they profit and the seller loses because without the option, the seller would have an asset they can sell at a better price. If the asset doesn’t increase in value, the buyer can choose not to buy, and the seller has profited by collecting the premium.

This is how the call option metaphor relates to technical debt. By taking a shortcut, you collect the premium: you have immediate profit because you’ve implemented a feature quickly, met the deadline, etc. If the code never needs to change again, you profit. You’ve collected the premium and the buyer never chooses to buy the asset.

But if things do change to your disadvantage, the profit of the premium disappears. For example, you might have to work in the bad code a lot because of feature requests. Or the code causes all kinds of bugs that you have to invest a lot of time and effort in. The option has been called, i.e. the buyer has chosen to buy the asset and you take the loss.

When the price of the financial asset doesn’t increase enough, the buyer would lose when calling the option. So they probably won’t, meaning you collect the premium and still own the asset.
When the option is called, the buyer profits because they buy an asset that is worth more than what they’re paying. But you lose because the asset is worth more than the premium you collected.

What this metaphor captures very nicely is not only the financial loss, but the uncertainty about it. You can analyze the current situation (the current market) and predict how things will evolve, but you’re taking a risk because you can’t know for sure. So is this a risk you’re willing to take?

Business people are trained to avoid risk and this metaphor can better explain the risk that we take when we implement a feature quickly without attention to good design and (automated) testing.

The Naked Stock Position Metaphor

The Naked Stock Position Metaphor is also rooted in the financial markets. But it’s slightly different. A naked stock position, is when you buy stocks (or other financial assets) without it being “hedged” from risk. Hedging means you make another investment that will (partly) compensate you when you lose money on your newly bought stocks.

For example, you could buy stocks, but also buy a sell option. This is similar to the call option I mentioned above. If the price of your stocks drops too low, you can sell them at a price higher than the market price. Still lower than what you bought them for, but at least you haven’t lost it all. Of course, the sell option comes at a price as well.

Without the hedging, you have what’s called a naked stock position. The rewards can be higher than with the hedging, but losses can be higher too. Again, this is about risk. You’re taking a risk for greater rewards. But if things don’t go the way you hoped for, you stand to lose a lot.

When we take on technical debt, we’re taking this risk without protecting ourselves (we’re not hedging our investment from risk).

The Software Inventory Metaphor

Let’s move away from finance and look at manufacturing. I was introduced to this metaphor by Dirk Jan Swagerman.

In manufacturing, companies have inventory: think about warehouses containing the different parts that are necessary to build the finished product, and warehouses containing the finished products, waiting to be shipped. This is inventory.

Companies want to keep their inventory low. Storing physical goods comes at a cost. Not shipping finished products means they have to be taken care of so that they’re still in perfect condition when you do ship them. You need a warehouse to store them. Having too many parts lying around is waste too. You need a larger warehouse, but you could also end up with excess parts if requirements change and certain parts are no longer necessary.

There’s all kinds of aspects to this, but managers are used to optimizing inventory. So how can we draw the line with software?

Every piece of software is something that needs to be maintained, taking up time and effort. The more complex the code is, the more time and effort it will consume.

Software can also go obsolete. For example, when a vendor stops supporting a piece of your application. Or when a feature is no longer used by end-users. These are opportunities to reduce waste. A manufacturing company will not keep products lying around that they can no longer sell. So why do software companies keep old products or unused code blocks in production? It’s waste that is costing us money.

This metaphor might be less fit to explain the cost of bad design, but it is a better way of explaining why we should retire code that is no longer used. It also helps managers understand the value of maintaining code that is running fine (by upgrading third-party libraries, frameworks, operating systems).

Photo by Petrebels on Unsplash

It Depends

It’s no coincidence that these metaphors occur in worlds that managers know and love: financial markets, physical inventory and loans. But you could invent new metaphors to explain technical debt. For example, if you’re explaining it to a passionate runner, you might say that technical debt is like starting fast in a 10K run. You’ll start ahead of your competition and maybe you’ll be able to keep that lead. But it’s also very likely that your competitor will be able to keep a steady pace and overtake you while you slow down because you’ve burned too much energy at once.

Find a metaphor your audience understands

I hope this helps you explain technical debt better to your managers and team. They can work for or against you, depending on who’s listening. And maybe that’s the important part: know who you’re talking to. Find a metaphor that they understand.

Leave a Reply

Your email address will not be published. Required fields are marked *