$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) ¹.

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.

What is technical debt?

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 Jacobson² 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 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:

• Delayed software update;
• Over-extended hardware lifetime;
• Poor design – when a software is not flexible enough to cater to ulterior changes in business requirements;
• Delayed refactoring – as business requirements change, some parts of the codebase will become inefficient and hard to maintain, and will need refactoring. The longer we delay the decision to refactor, the larger the codebase will grow, and the more our technical debt will have accumulated;
• Skipped documentation updates – as the codebase and functionality changes, the developer docs and user manuals will have to be updated accordingly. If this doesn't happen, we will lose precious time when we will have to perform further changes, or we will have to perform risky "band-aid" fixes.

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.

The cost of 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.

Corrective 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.

Adaptive maintenance

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%.

Perfective maintenance

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.

Preventive maintenance

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:

• Longer development cycles, which means users have to wait more for a change or new features. This leads to a lower customer satisfaction;
• Less qualified personnel who is willing to work on the project, higher training costs;
• Lower IT security, higher probability for breaches.

How to minimize technical debt?

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:

• Every software, framework and documentation should be constantly updated;
• Automated testing – automated tests allow developers to make changes to the code (be it a minor modification, a new feature or a refactor) without the fear of breaking functionality. Without tests, these changes are highly risky, and can lead to extreme development times and costs;
• Code reviews – a code review is the process where developers review each others code before it gets deployed into production. For a fresh set of eyes it is easier to catch issues could lead to errors later on;
• Root-cause analysis – if we do encounter errors or undesired functionality, it is worthwhile to spend some time researching, analysing, documenting the issue, and making change to our internal processes so that the same issue doesn't reoccur.

If we have already accumulated technical debt, it is important to manage it properly:

• Document debt – every necessary fix, update or refactoring should be documented. This is the most essential step towards making sure these steps are actually performed. This way, everyone will be aware of the extent of the technical debt, business will be more likely to acknowledge debt and spend the necessary resources to combat it;
• Refactoring – if some technical debt is already present, then it can be only decreased by refactoring. it is worthwhile to refactor the high business value debt first: code that is often affected by changes should be prioritized instead of code that is rarely or never changes. You should not wait until enough high-ticket tasks accumulate and then spend weeks only refactoring. Instead, repay debt while also doing valuable work. Determine how much of your maintenance and development time is set aside for refactoring (depending on the complexity of the technical debt, the recommended percentage is around 5%-33%).

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.

Conclusions

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.