Technical Debt is a nice metaphor coined by Ward Cunningham back in 1992. It’s now used by the whole software industry to describe the consequences of quick and dirty solutions leading poor software architecture and bad coding. The technical debt in a project introduces risk and basically means that in the mid to long term the health of your project will be negatively impacted because of unplanned work.
The great thing about technical debt is that you can quantify these parts of the software poorly designed and implemented in terms of money. It’s basically just like a financial debt. With financial debt, you spend money you haven’t earned yet (because it’s easier and faster) and this debt will cost you money again and again until you’ve got rid of the debt. With financial debt, it is similar. You take a shortcut, implement a quick and dirty solution (because it’s easier and faster) and end up paying for it every time you have to change the code to implement a new feature or fix a bug until you fixed the bad design/code and get rid of the debt.
And the quantity you get here is not only a list of violations (or a number of violations) but something you can express (just like a financial debt) in terms of cost of reimbursement. Now we come to the important part. Your management probably doesn’t understand a work, when you talk about code smells, code duplication, complexity… But when you speak in Dollars or Euros, they do get what it means.
So we’ve found the right tool to talk to management and convince them to fix things which are neither errors in the software nor new features, right ? Well, it’s not so easy. Just like with financial debt, it first sometimes makes sense to borrow money to get something out to the market before others. So it cannot really always be used to prevent violations and quick and dirty solutions. Second, as long as you are in growing phase (or at least as long as you haven’t noticed you’re not in it anymore), it’s mostly better to keep paying the interests and actually increase the debt to keep the grow pace high. The same thing happens with technical debt. Of course, from a cost perspective it’s cheaper to prevent technical debt or at least work on reducing it over time. But as long as your return on investment is high, you can get away with not doing it and focus on adding more features and conquering market shares.
The problem with the technical debt is also similar to the problem with the debt of industry nations. Of course, it’d be better to have no debt and if you keep increasing your debt instead of reducing it, you’ll get to the point that your debt is so high that you’ll not be able to repay it and will have to pay interests forever. And as with nation debts, politics does play a big role with technical debt. Especially the fact that in management as in politics, leaders are rarely sitting in the same seat forever. Politician doesn’t care about the debt in total because he’ll be long gone when the time comes where you cannot increase it anymore and need to pay back (if it ever happens).
Also, if you are the one spending money to reduce the debt instead of spending the money to support growth, you’ll end up with a negative record as noone will honor you debt-reducing activities but everybody will complain that you didn’t support grow as you should have. The same happens with technical debt. If you are a manager responsible for a product with a non-negligible technical debt, will you rather tackle the debt issue and spend a whole year fixing the dirty design and code or will you rather ignore the problem pay the interest and be the one who gain market share by having X great features implemented ?
So, is the message just to ignore technical debt and keep doing it quick and dirty to reach the goal faster even if the technical debt increases ? Well, there’s maybe a way between Mother Theresa and the filthy capitalist. Just like with financial debt, with technical debt, you pay different interest rates depending on what caused the debt (or in the financial case, where/when you borrowed the money). So one solution is to reduce the debt on which you pay a high interest rate i.e. fix the violations which will cause high maintenance costs and first live with the many violations (which in total represent a huge amount of money) which are less costly in the long term.
Also as long as the dept is combined with a high growth, it’s less of a problem (do you ever year about the public debt of nations with 2 digit growth figures ?). If you closely monitor your growth, you might notice a loss of speed and if your technical debt is high, you can bet that it’s partly due to it. At this point in time (when the debt starts to have a negative impact on growth), you’ll have to start dealing with it. Of course, you’re in a better position if you’ve been appointment to a position because growth is suffering. Then you can more easily implement long needed measures than if you were the guy delivering XX% yearly growth and now need to handle debt because growth is slowing down.
Another thing you have to keep in mind is that even though there are a lot of similar aspects, technical debt and financial debt are not exactly the same.
First, there are cases in technical debt, where you do not have to pay interests. It happens if your piece of code contains no error and never needs to be updated. Of course, in many cases, there will be errors even if it might well happen that new features never require change. So it’s a thing you need to evaluate when considering which technical debt has to be dealt with.
Second, if you are not sure you want to keep the software, you might end up getting rid of it and with it goes the technical debt (without having to repay it). Maybe you can compare it with a state bankruptcy…
Last, one big difference is that it’s easy to measure financial debt. But it’s not so easy to measure technical debt. You know the number of violations. But you do not know the actual cost to fix them. You just have to use some kind of half way reasonable averages.
So handling technical debt requires a lot of weighing and thinking but it’s at least good for some people: consultants and vendors. It is easier to scare businesses into buying consulting time or tools using technical debt than with purely technical issues.