What Is Tech Debt and How to Explain It to Non-Technical People?

Probably anyone who is connected to software development has heard about technical debt. But both salespeople, account managers and probably even CEOs rarely understand what tech debt means, how to measure technical debt, as well as the necessity to pay it. According to Claranet's survey, 48% of 100 IT decision-makers from the UK, say that their non – technical coworkers have no idea about the financial impact of tech debt.

At the same time, the risks of not resolving technical debt must be clear not only to developers but also to other members of the team. This will help to acknowledge the need for changes and provide an understanding of why not every feature/project can be implemented quickly. But the question remains — how to explain tech debt to a non-technical audience?

How Can We Define Tech Debt?

Technical debt or code debt is a metaphor that refers to all consequences that arise due to poorly written code and compromises in the development. This concept, in particular, includes the extra effort that has to be done to improve the software or to add additional functionality.

Probably the best way to explain the term “technical debt” is with the help of an analogy said by Alex Gostev, Project Portfolio Manager at QArea.

“I like very much the definition of technical debt provided by Wikipedia: technical debt can be compared to monetary debt. What does it mean? If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. It’s the best definition that was coined by tech specialist (American programmer Ward Cunningham) to justify refactoring costs in front of the CFO of a company.”

It is quite easy to explain the concept of tech debt to business owners. It is like taking a credit. For example, you can take out a loan to open a new office for the company. If you take that credit to carry out this plan, the interest occurs. In other words, you will pay more in the long run.

Some metaphoric parallels with real-life can also be a useful tool for explaining tech debt issues to non-tech specialists. We can talk about technical debt as of some mess in the house, for example in the kitchen area. Imagine that you have cooked your dinner you decide to leave the kitchen without cleaning up. You continue to do it every day and at some point, the kitchen (read “software”) becomes chaotic so it is impossible to cook (read “add new features”) there anymore.

Sometimes it is better to explain tech debt with hard numbers rather than expect to persuade people with metaphors. “I’d advise to properly set up an experiment within the company linking refactoring work with positive dynamics in metrics that can be translated into numbers — fewer hours of work for maintaining code base, less re-appearing bugs, the higher amount of customer complaints resolved,” Gostev stresses.

It is also important to mention different reasons for technical debt that can influence its scope or, in some cases, justify its ends.

What Are the Types of Technical Debt?

We can distinguish at least three types of technical debt. Even if developers don’t compromise on quality and try to build future-proof code, the debts can arise involuntarily. This can be provoked by the constant changes in the requirements or the development of the system.

Your design turned out to be flawed and you can’t add new features quickly and easily but it wasn’t your fault or decision. In this case, we’re talking about accidental or unavoidable tech debt.

The second type of technical debt is deliberate debt that appears as a result of a well-considered decision. Even if the team understands that there is a right way to write the code and the fast way to write the code it may go with the second one. Often. it makes sense – as in the case with startups aimed at delivering their products to market very quickly to outpace their competitors.

Finally, the third type of tech debt refers to situations when developers didn’t have enough skills or experience to follow the best specific practice that leads to really bad code. The bad code can also appear when developers didn’t take enough time and effort to understand the system they are working with, miss things or vice versa perform too many changes.

The Cost of Tech Debt

Technical debt is a problem that needs to be addressed, no doubt about that. You can start with a significant level of tech debt due to some reasons but reduce it as you go along by refactoring so the damage will be minimized or eliminated. But if you let the technical debt accumulate, there will be real consequences.

For example, tech debt can lead to cash costs such as a need to recruit more people to maintain the system or extra time required to build new features. According to Appian, technical debt consumes 40% of development time and results in higher operational expenses. Tech debt may become the reason for fines due to security breaches or lost sales following the system outages.

Non-cash costs of the tech debt can be pretty harmful to your business too. Tech debt can lead to an inability to complete user-experience improvements or adapt to the changes in the market. And it can result in lower levels of productivity because of systems outages or the necessity to spend a significant amount of time on extracting but not on analyzing the data.

Even the most well-known companies had to tackle tech debt at some point in their evolution. According to Forbes, the Twitter decision to build its platform’s front end on Ruby on Rails eventually made it difficult to optimize search performance and add new features. Twitter responded properly and switched to a Java server, which allowed the company to decrease the search latency significantly. In this way, Twitter paid its tech debt.

It is crucial to be mindful of the risks associated with tech debt, but you should also keep in mind that not all debt necessarily becomes a big problem.

“Causes or roots of tech debt should be understood within the team to find out what techniques or approaches produce an inexcusable result. That will be the bad technical debt to fight against. Everything else – we can call it good/soft/tolerable technical debt – can be eliminated out of the equation.”
— Dmitriy Barbashov, the Chief Technology Officer at QA

Further Reading

The Three Secret Types of Technical Debt

Technical Debt: How to Balance Between the Velocity of Production and Code Quality?