Technical Debt

The software development life cycle is rarely a straightforward path. Client needs often change during development, and unexpected roadblocks may pop up at any time. Deadlines, as a result, may not always be achievable, even with software best practices in place. That’s why sometimes, it’s necessary to borrow from the future, so to speak, in order to achieve delivery schedules in the present. This is where the concept of technical debt comes in. 

In this glossary article, we explain what technical debt is, what causes it to accumulate and whether it’s explicitly a bad thing in all cases.

What is Technical Debt?

Technical debt is the implicit generation of additional code refactoring work in the future, brought about by the need to expedite code delivery in the present. 

It is essentially a tradeoff between speed and quality when it comes to software delivery. You skip steps or choose less-efficient, but faster, solutions in order to meet your deadlines now. The problem is, this means having to fix the issues that this decision will cause later on. The future resources that will need to be spent on these fixes are technical debt.

What are the Consequences of Accumulating It?

One of the most important consequences of this kind of debt is that it can accumulate “interest.” 

The longer it goes “unpaid”—that is, unresolved or unreplaced by better code after deadlines are met—the more resources it costs to “pay off.” Unwieldy code caused by technical debt becomes more deeply integrated into the software over time. It may become harder and harder to remove without requiring changes to the rest of the code as well.

The Types of Technical Debt

There are two principal types of technical debt that you may encounter.

Intentional

Intentional debt is generated as a result of a company’s explicit decision to rush code. 

One example of this in video game development is bugs and performance issues that a company leaves unresolved in order to meet a publisher’s launch deadline. The game may launch as planned, but players may experience performance issues until the release of a post-launch patch.

Unintentional

Unintentional debt is caused by factors that aren’t explicitly decided on. For example, poor quality code may accumulate due to the work of inexperienced developers who are learning a new framework. This type of debt may be discovered in retrospect after developers have learned better practices and solutions. 

The natural need to update code over time can also be the cause of unintentional debt. Operating systems experience this frequently, as they require new driver and security updates on a regular basis.

Is Technical Debt Bad?

Just like its financial namesake, technical debt is not an explicitly bad thing. Rather, it’s an instrument that may be used to achieve certain goals when quality is not necessarily the top priority.

For example, if your business is trying to beat the competition to market, you may opt to use technical debt to speed up delivery. You do this with the understanding that you’ll need to rework the code later on, but you’ve already calculated that you can ease up on other development tasks to account for refactoring work. You also calculate that your earlier arrival on the market would create profits and share of wallet that would certainly exceed the cost of the refactoring work.

In this scenario, the competitive advantage secured by your rapid delivery is valuable enough to consider the accumulation of debt.

The problem is that it can be hard to detect. Unlike financial debt, which is clearly visible on a balance sheet, this is an implicit cost. It’s difficult to predict how much effort it will cost to refactor technical debt that has already shipped with production code.

How Do You Manage It?

Technical debt may be unavoidable for many companies, but it can be managed with the right best practices.

1. Ensure That All Debt is Accounted For

As mentioned, technical debt can be hard to detect. To remedy this, a culture of transparency and accountability may help. One way to do this is to include discussions about it in every scrum meeting, to keep stakeholders aware of its progress. You can also include visualizations of the debt in your progress charts and task lists.

2. “Pay off” Your Debt at Every Sprint

Just as financial debt may have minimum payments at certain intervals, you need to devote a certain amount of your development resources to paying off debt. This prevents the accumulation of “interest” over time. One good practice is to allocate 15-20% of man-hours to the resolution of technical debt.

3. Implement Rigorous, Standardized Code Review 

Even if you account for all the intentional debt, there’s still the matter of unintentional deficit that may be even harder to detect. Improving your code review practices can help catch this type of debt before it affects your development too much.

Technical Debt: Neither Friend Nor Foe

Technical debt is a common practice that many agile teams are likely to encounter in any time-constraint development process—which, of course, describes nearly all types of enterprise development. 

It’s important to note that it’s not necessarily a bad thing to accumulate this kind of debt if the advantages of doing so are aligned with business goals. However, runaway technical deficit can be a serious problem over time. You need to equip yourself with the best practices of technical debt management to prevent the “interest” from exceeding the returns you hoped to get.