What is technical debt

June 13th, 2014

Technical debt means saving money on development now but paying more money later. Let me explain this concept in detail.

What is a debt?

It's called a technical "debt" because it works like any other debt. Say you want a $100K house today, but you don't have that money upfront. That's what mortgages are for. If you split this over 25 years with a 5% interest, you'll pay just $585 per month. In the meantime, you can start living in that house. 5% seems like a small rate, but after 25 years, you would have paid $175K. That's nearly double!

How do you incur a debt in IT?

Say you want a new functionality today, but you don't want to spend too much time implementing it. You can use a shortcut such as doing a quick and dirty patch. That decision comes with an interest, because you'll need to put in a little extra effort each time you work on code that is related to that patch. This interest also compounds, because all your efforts will be hindered by that messy piece of code. There are other reasons for technical debt:

• No documentation can slow down development because other team members have to figure everything out by themselves, possibly making mistakes.
• No automated tests can lead to extra debugging, because code that used to work got broken and nobody noticed.
• Delayed refactoring can lead to extra effort, since you have to work with code that is difficult to maintain.
• Etc.

It's not always bad

When people talk about technical debt, it usually sounds as something that should be avoided at all cost. But does it make sense to rent an apartment for 25 years while you're saving up for a house? Rent is not free and few would wait decades just so that they could purchase the house cash. You need to calculate which option makes more sense. It's not black and white, either. You can rent a few years while you save up for a downpayment and then take a smaller mortgage.

An IT project is similar. While you pay your developers to work on a feature, you're not making money from it, because the feature is not ready. You need to find a compromise between the cost of the debt and the cost of postponing the release. Once you start collecting profits, you can have enough money to fix the code and do things properly, until the debt is fully paid.

It can be really good

Many people don't know it, but it's possible to take a loan only to reinvest it at a higher rate. Taking risk into account, the outcome can be very good.

Technical debt works the same: you can rush the product or feature now, accept that debt, but get more customers more quickly. These customers may be more than enough to pay for salaries to hire a bigger team and refactor that code to eliminate the debt. Like with the investments, you have to weigh how much extra work the technical debt adds versus how much you'll get from the extra business. I have seen solo entrepreneurs launched into a half-million dollar income in the span of a few years, which was more than enough to progressively refactor the code.

Conclusion

Debt simply refers to an obligation to pay back. It's not inherently bad, since you get something in return. You should understand how much a decision will really cost you, what value you'll get, and manage all your debts in a smart way.

Previous: How to kill creativity, part 2 Next: Common PHP Mistakes