$517 billion dollars. We rarely see an amount that large, so I'm going to type it out in digits as well: $517 000 000 000. That's nine 0's there. This sum represents the technical debt of the US in 2018, according to CISQ (Consortium for IT Software Quality) 1.
Based on the above, we can undoubtedly state that having technical debt is costly. It's also important, the tech industry writes a lot on the topic. We already mentioned it ourselves on a couple of occasions, right here on our own blog (like here or here). In spite of this, there are just a handful of people who are in the know about technical debt outside the tech industry. This article is geared towards them.
It's not nice to be indebted to someone. The more debt we accumulate, the bigger the pressure on our shoulders. If you ever spoke to someone who managed to repay all his debts, they will most probably describe the feeling as "liberating".
Technical debt is very similar to financial debt (hence the name). Just as with financial debt, technical debt also requires you to pay an interest. This interest can come in many shapes or forms: high maintenance, support or legal costs, the extreme costs of migrating from a legacy system or unmotivated staff.
If we don't repay our debt before taking on new developments, we will constantly incur obstacles which will require us to take out another loan, increasing our debt. The higher the debt, the slower we will be able to progress. At some point, our development will be completely crippled by technical debt.
This crippling effect is called software entropy. The second law of thermodynamics states that a closed system's disorder cannot be reduced, it can only remain constant or increase. The measure of this disorder is entropy. Ivar Jacobson2 was the first who drew a parallel with software development: if we make constant changes to a software, without performing the necessary maintenance and upkeep, it's disorder (or entropy) will increase.
A good example for this would be an ERP software. Such a system is constantly changing because of the changing business environment. If you don't keep the documentation up-to-date, don't maintain the code or do not perform the necessary technological updates, then we fall into a vicious circle: we need to perform these change in order for the software to be efficient and make us money, but to do so would require so much time and money that it's just not worth it anymore. In cases such as this, our only option is to "rip and replace" the complete system.
Technical debt is a forward-looking metric that represents the incremental cost to a company as a result of prior decisions that were made to save time or money when implementing new systems or maintaining existing ones.
Imagine your existing IT systems… Now imagine how these systems would look like, if you would start an ideal system from scratch today. How much would it cost to modify the current systems, to achieve the same ideal system? This sum is your technical debt.
What leads to the accumulation of technical debt is usually a compromised decision. This compromise may stem from a lack of time or lack of money.
Some examples of this decision might be:
Technical debt is unavoidable. Software and hardware is being developed at unprecedented speeds, with new updates and security fixes every day, that the passing time alone results in technical debt.
Technical debt is inherently part of existing software products. But because the reduction of technical debt is not really quantifiable, IT has a hard time explaining to business, why resources are necessary to combat debt.
Perhaps, the easiest way to explain this, is to understand what goes into maintaining and operating a software system. Herb Krasner, the author of the CISQ report identifies 4 types of maintenance.
This is the process of correcting issues that are found after deploying a software into production. Technical debt greatly contributes to the need for corrective maintenance: the larger our debt is, the less transparent and maintainable our code becomes, which leads to further errors.
Corrective maintenance accounts for roughly 20% of the total maintenance costs.
The changes that are necessary because of a changing business landscape are called adaptive changes. Similarly to corrective maintenance, technical debt affects how easy it is to perform adaptive maintenance.
Adaptive maintenance is the largest chunk of our total maintenance costs, at about 50%.
Apart from correcting errors and modifications because of the changing business requirements, perfecting a software, such as usability or performance improvements, also requires a lot of resources and effort. As with corrective and adaptive maintenance, how easy it is to perform these improvements largely depends on the amount of technical debt we have accumulated.
Perfective maintenance is around 25% of the total maintenance costs.
The activity to discover and correct latent defects, before they become effective defects is called preventive maintenance. These activities include performing software updates, security updates, code refactoring, but also keeping the documentation updated.
Preventive maintenance accounts for only 5% of the total costs, however, if neglected, it can significantly increase the costs of corrective, adaptive and perfective maintenance. This can be see on the below figure.
Apart from the direct increase in costs, technical debt also has indirect effects, such as:
We already stated that it is impossible to get rid of technical debt entirely. There are however some methods that development teams can adopt to ensure better code quality which leads to a slower accumulation of technical debt:
If we have already accumulated technical debt, it is important to manage it properly:
There are some (rare) occasions when it is acceptable to ignore technical debt. This could be for instance when a product is nearing its end-of-life, or when the sole purpose of the product was to validate an idea or market, as is the case of a prototype or MVP.
Technical debt is unavoidable, a collateral of any IT project. Avoiding it, or just constantly delaying the necessary actions will sooner or later cripple the entire system, and the business with it.
Because of this, good development teams do not accumulate technical debt, but manage it in a timely fashion. Software and documentation is always up-to-date, code quality is ensured by automated tests and code reviews, and they also constantly refactor the code parallel to developing new features.