What is technical debt? How to pay it off (with examples)

Summary

Technical debt is the cost of additional work caused by choosing the quickest solution rather than the most effective solution. Though there are times where technical debt is worth it, it’s important that your team understands the positives and negatives of speedy decisions and how to manage rework in an efficient way. In this article, we explain what technical debt is, share techniques to avoid debt, and take a look at how to differentiate between valuable vs. not valuable decisions.

Working in the product space often requires quick decisions about software features. If you’ve ever worked in a DevOps team, you know just how many decisions are needed to push features live.

Technical debt is the term used to describe the result of making decisions based on speed above all else. These quick, real-time decisions can make or break software updates. But there should be a balance between good decisions and fast ones. Incurring tech debt can result in negative outcomes or be well worth it—depending on what you and your team decides.

In this article, we’ll discuss the definition of technical debt, how to effectively manage quick decisions in the development process, and share examples to give you a better understanding of how to avoid future mishaps.

What exactly is technical debt?

Technical debt is the cost of additional rework caused by choosing the quickest solution rather than the most effective solution. Technical debt is a phrase originally coined by software developer Ward Cunningham in 1992, though the term has evolved since then.

Today, technical debt, also known as tech debt and code debt, usually occurs when development teams choose to write speedy code while building new features of a software development product. Speedy code delivery can help your team meet deadlines, and the debt you accrue be worth it, though it could also lead to negative outcomes if managed incorrectly. These negative outcomes aren’t always avoidable once the decision to accrue technical debt has been made.

Whether you’re experiencing a good or bad outcome, we’ll go over the important facts about technical debt so you’re prepared to make the right decisions in the moment.

Is technical debt bad?

Much like financial debt, technical debt can be utilized in both good and bad ways.

In some instances, tech debt is the result of a calculated move to both meet software deadlines and ship high quality code within sprints. In other instances, technical debt is the result of an unavoidable mistake made when releasing a software update.

The technical debt quadrants

There are four different causes of technical debt—referred to as the technical debt quadrants. The four technical debt quadrants, coined by Martin Fowler, include reckless, prudent, deliberate, and inadvertent.

Assigning technical debt to these quadrants helps gauge intent and background on code issues. While some code debt may be deliberate and classified as , other codes may be inadvertent and classified as .

Prudent and deliberate: The decision to ship quickly and deal with the consequences later causes prudent and deliberate debt. This type of debt is most commonly used when the stakes of the product are relatively low, and the benefits of a quick delivery outweigh the risk.

Reckless and deliberate: Knowing how to produce the best code but prioritizing speedy delivery over it is the cause of reckless and deliberate debt.

Prudent and inadvertent: Prudent and inadvertent debt happens when there’s a desire to produce the best code, but you find a better solution after implementation.

Reckless and inadvertent: Reckless and inadvertent debt occurs when a team tries to produce the best code without the necessary knowledge to do so. The team is often unaware of the mistakes they’re making.

Teams choose deliberate technical debt for the sake of speedy delivery, while inadvertent debt is accidental—it happens after implementation. This difference is best described by software engineer Steve McConnell when describing the two overall types of technical debt. Let’s dive into each of these to gain a better understanding.

Types of technical debt

Steve McConnell, Chief Software Engineer at Construx Software, suggested that there are two types of technical debt :

Intentional

Unintentional

1. Intentional technical debt

Intentional debt occurs when an organization makes a conscious decision to optimize for the present rather than for the future.

There are both short-term and long-term variations of intentional debt. For example, intentional debt accrued to pay off a former debt is short-term debt, while an intentional debt accrued to prevent a larger future debt would be a long-term debt.

Short-term debt : Short-term debt is incurred reactively, for tactical reasons such as to use existing resources. Additionally, short term debt can be focused or unfocused.

Focused short-term debt: This includes individually identifiable shortcuts.

Unfocused short-term debt: This includes numerous tiny shortcuts.

Long-term debt : Long-term debt is incurred proactively, for strategic reasons such as to meet a deadline.

As you can see, the type of debt accrued will dictate how long it will take to pay off.

2. Unintentional technical debt

On the other hand, unintentional technical debt happens due to a lack of understanding, accidental mistakes, or—in some cases—poorly written code. An example of unintentional technical debt would be a design approach that turns out to be error-prone. This is the non-strategic result of making an unavoidable mistake.

We can assume unintentional technical debt as accidental as the team did not incur it on purpose. Most commonly, you will only realize your mistake after you implement the software update or complete the project.

How to get rid of technical debt

While you may accrue some technical debt intentionally, many product teams struggle to track and communicate tech debt. This can result in more work than anticipated when looking to solve the gaps in software code.

There are two main ways to manage technical debt and create greater workplace transparency around debt load.

Maintain a debt list within a tracking system: Each time you incur debt, enter the tasks needed to pay off that debt into your tracking system along with an estimated effort and schedule. Use the debt backlog to track your tech debt progress. Any unresolved debt more than 90 days old should be treated as critical.

Maintain the debt list as part of a Scrum product backlog: Treat each debt as a Scrum “story” and estimate the effort and schedule to pay off each debt—the same way you estimate other stories in Scrum within a product backlog .

Both of these methods can help you effectively track technical debt and get rid of debt as quickly and efficiently as possible. Similar to paying off a credit card, both approaches allow you to pay off small increments of debt until the grand total is paid off.

Technical debt examples and solutions

Now that you have an understanding of managing technical debt and some of the causes behind unintentional and intentional debt, let’s review some real life examples.

Example 1: Intentional technical debt

Description: The team chooses a framework that is fast to build on, with known performance issues and minimal functionality capabilities.

Solution: The team uses additional applications for post software implementation that features the missing framework functionality.

Debt: Though they met the product deadline, the team will need to rework the features after launch and will require additional funds.

Example 2: Unintentional technical debt

Description: The team has many junior developers helping to launch a new software feature on a tight deadline with not enough senior developers to review each piece of the code.

Solution: The team hires additional temporary support from senior developers to look over the code and check for proper functionality.

Debt: While the team caught most of the issues, the miscommunication between full time staff and temporary support caused oversight on some missed bugs in the code. This means the team will need to debug these issues post-launch.

As you can see, while different, both intentional and unintentional debt will need to be paid off over time. By brainstorming a solution to technical debt, you can ensure your software updates launch on time, with little debt accrued.

Pay off your technical debt with transparency

Debt isn’t always avoidable when working on a software product launch. From tough decisions to mistakes in code, Agile teams know how the amount of technical debt accrued can affect software updates.

The key to paying off debt is to maintain and track incremental payments. While the type of debt payoff is different in each scenario, team transparency and communication can help pay off your debt faster. This is because enhanced clarity on Agile projects can enforce a collective solution to the problem at hand.