The term “technical debt” is a metaphor coined by Ward Cunningham in 1992, trying to explain why every software project over the course of time continues to need technical maintenance. There is something strange about how code can “age”: even if you did your best to get everything correct and readable, six months later your code may seem riddled with bugs and utterly impossible to understand. How did that happen?
The metaphor of technical debt is a very powerful one, because it explains a mysterious technical process using something everybody understands and can relate to: monetary debt. Look for example at the figure below, which works just as well for technical debt as for monetary debt.
Imagine you want to build a software component, or a house, and you have to invest 1,000 Ŧ in order to get it (Ŧ being an imaginary technical currency). If you’ve ever built a house, or a software component, you’ll probably know that the value of the product that you’ll get will be slightly less than what you had to put in. Say in our case that the value of the product is 950 Ŧ. What you then end up with is a technical debt of 50 Ŧ, which is not so much. However, if you don’t make your monthly payments, your debt will start to increase.
In the real world, monetary debt can become larger than the value of your house. I guess there are ways in which that would be possible for a software project too, especially if you think about components that may be critical to your business if they brake down because of bugs. But in most circumstances, I would guess technical debt is rather limited, and can’t become larger than that it makes your project worthless. The key point is, however, that you should try to keep the amount of technical debt in your project under control, like in the picture below, and never let it go out of hand like in the picture above.
The term technical debt has been used a lot over the years. There have been built tools that try to measure technical debt, and even express it in real money value. Other people have used the term to explain other phenomena in software projects. I’m not so fond of people who advocate that it’s a good or a smart thing to take on technical debt deliberately, as an “investment” in a project. They say it’s like going to the bank in the real world, but I’ve never understood where that “technical bank” is, and how it’s handing out the money.
There’s one strange thing about technical debt that has taken me some time to understand. Why is it that sometimes, technical debt jumps up abruptly? Especially if you’re using a library that has just released a new version, you suddenly find yourself sitting around with a lot more technical debt. And that happens literally overnight. Does the metaphor work for that too?
I think it does. Using a software library is a bit like taking up a loan in a foreign currency. Your house has a value in your local currency, but your debt is expressed in a foreign currency. If the other country suddenly decides to revaluate its currency, you have a problem.
Let’s take a look at the figure below, illustrating what happens if the revaluation is relatively small. We start out with a loan of 1,000 Ł and an asset value of 950 Ŧ. As long as parity is maintained between the two imaginary currencies (1 Ł = 1 Ŧ), everything is fine. But what if the value of the foreign currency is suddenly increased by 5 %? When that happens, your technical debt is in effect increased with 50 Ŧ (1,000 Ł = 1,050 Ŧ). Luckily that’s not so much, so you can probably pay down the extra technical debt very quickly.
The case above is much like a new minor version of a software library being released. When you try to adopt the new version, most things still work, but there may be a few things here and there that you have to adjust. If you implemented a work-around for a small bug in the software library, you may have to remove it. Maybe there’s a method that’s still supported, but now deprecated, and you want to clean that up. Those kinds of things.
Things become a bit more dramatic when a major version is released. That would be like in the figure below, where the foreign currency is suddenly revaluated with 40 %. Worst of all: it happens right at a moment when you’re a bit short on technical cash (you’re e.g. in the middle of a user acceptance test), so you’ll have to postpone the upgrade for a while. That means that you’ll have to incur some extra technical debt, because any new code that you add to your project will be based on the old version of the library, and therefore will have to be upgraded to.
When you look at technical debt and software libraries in this way, one thing becomes very clear: when a new major version is released, you really want to upgrade as soon as possible. Probably the best time to do so is at the beginning of the next development cycle. That way you have time to catch many of the bugs related to the upgrade. If you postpone the upgrade, the technical debt in your project will quickly get out of control. The worst thing of all would be to wait for the next major release of the library. If it’s already too expensive to upgrade your project for one major release, then why do you think it will be easier or cheaper to upgrade for two or even more major releases–at the same time?