Debts arise when you spend more than you can afford. Furthermore, debts grow by itself: they come with an interest rate. Debts do not have to be a problem, as long as they are temporary, and as long as you have the means to pay them back. Because this is the number 1 characteristic of debts: they need to be paid back, one day or another. If you can’t pay them back at the moment when you have to, this leads to serious consequences: you might lose your house, or you might get blacklisted by banks.

Most debts are financial: you owe money to a bank for your mortgage, or for the new car you bought last year. These debts can be expressed in clear financial numbers, which makes them easy to identify, analyze and manage.

In the world of software development, debts exist that cannot be easily expressed in numbers. It’s called technical debt.

In this article I will explain what it is, compare it to financial debt and describe some guidelines  on how to deal with it.

What Is Technical Debt?

Technical debts are introduced by sub-optimal technical decisions. That’s rather abstract, so let me give an example. Let’s say your current software application works with the euro currency only. But business is expanding to areas outside of the euro zone, and now an important potential customer requires your system to also support the American dollar. What do you do? Basically, you have two options.
The first option you have is: you implement the requirement in such way that your system simply supports both euro and dollar. Your software programmers explain that it is relatively easy, although it requires a lot of code that they call ugly: a lot of ‘if currency = EUR then …’ constructions, for instance, something which makes testing and debugging more difficult.
The other option is: create the possibility to use any kind of currency in the system. Your software programmers explain that this is harder to implement, it will take more time, but the resulting system will be cleaner and easier to maintain.

The example is not 100% technical, but I hope you get the idea: there are situations where you can choose quick wins, or go for more solid (yet more expensive) technical solutions.

Short Term Versus Long Term Profit

And so we arrive at the crucial question: do you choose a short term profit (please your new customer as fast as you can), or do you choose to invest in the future (create a solid solution that will support a broad range of future requirements, including the urgent one of your new customer)?
Choosing the short term route generates fast and measurable profits (revenue because of a new customer). However, chances are you create technical debt here, debt that is not visible immediately.
Choosing the long term, you may have to tell the new customer that he has to wait longer before your system can comply with his requirements. You will have to invest more than in the short term solution, which will affect immediate profit negatively. On the other hand, your system will become more future proof, and future new customers with yet another new currency can be pulled onboard without any effort.

The Interest Rate: High Maintenance And Low Production

And this is a very important reason why technical debts arise: technical decisions that support short term profits, instead of long term profits. The more this happens, the larger will become the amount of technical debt. But remember: it comes with an interest rate! So the bigger the technical debt becomes, the more interest you pay. Or expressed in software development terms: you will spend more and more time on basic maintenance tasks (bug fixes, implement small features), and less and less time on what you would need to do (develop your system according to the new requirements of your markets: i.e. create value for your customers).

Guidelines For Dealing With Technical Debt

It’s OK to have some debts (probably inevitable in software development), it would be even OK to have a considerable amount of debt.
However, as a technical manager you cannot just let it grow, that would be very irresponsible, not to mention bad management practice. Maintenance costs could literally kill your company. So what to do?

• As technical debt is not very visible, make it visible: identify the moments when technical debts arise, and document it. Ways to do this: talk to your technical specialists, actively discuss the consequences of certain technical solutions for your technical debt. If technical debt is already there, have your system be reviewed by independent software quality experts.
• Subsequently create a plan for payback. Make an estimate (i.e. risk analysis) of the interest rate (how does the technical debt affect your productivity), and decide when and how you are going to pay back. Remember that the exact moment that you urgently need to payback (for instance when the technical debt would block the development of a new required feature) is quite unpredictable. In general it is good practice to pay back your debts before you are urged to pack back.

When Technical Debt Has Become Very Big

When I’m contracted by a company, usually the technical debt is already way too high. It’s sometimes so high that investments of millions of euros would be necessary to pay back all the debt. The problem is: money itself is not making the debt disappear. Money needs to finance the right activities that will pay back the debts. When the debt is very big, it has also become very hard to identify which activities are needed. When the house is almost collapsing, should you try to renovate it or should you just build a new house?
In one of my next blogs I will address this situation.

Differences With Financial Debts

As you may have noticed by now, technical debts share some characteristics with financial debts. To conclude this article I will summarize the most important differences previously mentioned:

Technical debt is not very visible and can not be easily put in numbers. This makes it harder to manage, especially by managers that do not completely understand the concept of technical debt. This is one of the reasons why software departments are very hard to manage by managers without a firm background in software development.

It’s hard to predict when it’s payback time. For your mortgage, your bank will tell you exactly when and how much to pay. In the case of technical debt, most of the times you don’t know when it’s payback time. It might take years before you need to pay something back, it could also be tomorrow.

Resolving technical debt requires investments. Financial debts you resolve with plain money. But to resolve technical debts, you need to invest! Invest in the right people, right activities. And, like all investments, they come at their own risk. Another reason why it’s so hard to get rid of technical debt: activities that are supposed to get rid of it might even increase the technical debt!