When we talk about being in debt, we usually think of financial debt. It’s simply a way to get something now with the promise to pay for it later. But debt can be costly as interest piles up and you struggle to pay off what you owe.

Technical debt is similar to financial debt in that you’re making a tradeoff for something now that will need to be paid back later. In this article, we’ll explore what technical debt is and look at ways to reduce it.

What is technical debt in Agile?

Ward Cunningham, one of the authors of the Manifesto for Agile Software Development, once said something to the effect that deferring work on problematic code is like taking on financial debt. In both cases, you’re borrowing against the future, but you’ll eventually need to pay off the debt.

Cunningham called this technical debt. Basically it means that there are going to be tradeoffs in a project. You might have to cut a few corners to meet deadlines and get some much needed revenue. But, you will eventually have to pay back that debt by fixing the problem later. You’ll have to determine which is the better option: taking on technical debt to release the product faster or delaying the release to fix the problem now. 

What are the consequences of technical debt?

Sometimes going into debt is the only thing you can do. For example, taking out a 30-year loan to buy a house makes sense if you can afford the monthly payments. Similarly, it might be worth it to put off some work until later if it means you can make customers happy now. 

But even justifiable debt is still debt. It doesn’t go away on its own, and you'll eventually need to pay it off. The consequences of taking on technical debt include:

• Reduces forward motion: Too much debt means that you’ll spend too much time and resources fixing previous problems later, which can keep your team from working on features.
• Can be costly: Technical debt interest can cost more later than if you would have fixed the problem before releasing the product. It can also be a financial burden as you throw more resources at the debt or hire new employees.
• Is self-perpetuating: Technical debt can grow because nobody really likes to work on it. Working off technical debt can be time-consuming, tedious, and can lower employee morale.
• Can lead to poorly designed code: If too many shortcuts are taken to get a faster release, it could lead to messy code that is harder to fix down the line.
• Poor product performance: Pushing out a product before it’s ready might bring in quick money, but too many bugs could make customers unhappy and end up losing you money in the long run.

Examples of technical debt

Every developer wants to write the best code that they can. But things happen such as, the team is pressured to release new features before they’re completely ready, or management and other developers don’t understand the consequences of technical debt. These things can lead to different types of technical debt including:

• Source code formatting: Sometimes bad code is added to the codebase. Maybe modules aren’t named correctly or consistently, or you’ve used some uncommon practices as a quick fix that are hard for others to read. A problem in the source code is one of the most common technical debt examples. These can usually be quickly identified and fixed, unless you continue to add bad programming on top of them.
• Poor documentation: You might not think of documentation as a type of technical debt. But if developers create code without documenting what they have done, the documentation becomes technical debt. Lack of documentation might force developers to spend too much time digging through lines of code to figure out what broke and when it broke. Also, documentation is important to bring new people up to speed on the project.
• Intentional technical debt: This doesn’t mean that you intentionally write bad code so you can work on it later. Instead, it means that you intentionally decide to solve short-term problems by using shortcuts that can be easily fixed later. You might do this to realize necessary gains. This can work well if the team does the fixes quickly and doesn’t let more debt build on top of it. If stakeholders have unrealistic expectations or your deadlines are too ambitious, you might find yourself relying too heavily on intentional technical debt.
• Unintentional technical debt: This can happen when legitimate mistakes are made. Maybe you have new people on the team or less experienced code writers working a tight deadline and there weren’t enough senior developers to adequately review the code.

Measuring technical debt

Is technical debt always bad? Let’s look at the financial metaphor. If you take out loans to go to college, that might be considered good debt, depending on what your major is and its potential to earn you a good living in the future. But this “good” debt is still debt. And it could take years to climb out from underneath it.

So as you work on your projects, you will likely accumulate technical debt. To keep your technical debt in control, you need a way to measure it so you can determine if the debt makes sense or not.

The technical debt quadrant is a tool that is often used to help teams measure and manage technical debt.

The technical debt quadrant

Martin Fowler created the technical debt quadrant built on these two questions:

1. Did we get into this technical debt deliberately or inadvertently?
2. Was the decision to take on the debt reckless or prudent?

The answers to these questions form the quadrant with “deliberate” and “inadvertent” listed vertically and “reckless” and “prudent” listed horizontally. 

Let’s take a quick look at each quadrant:

• Deliberate & Reckless: This quadrant is the least desirable because you know that the choice you make will create technical debt. You might not have thought everything through and you’re not sure how you will address the debt later.  
• Deliberate & Prudent: In this scenario you are trying to make a more informed decision about the debt you are willing to take on. You carefully weigh the risks versus the rewards, and you think of ideas for dealing with the consequences of your decision later.
• Inadvertent & Reckless: This quadrant falls under the “oops, I should have known better” category. Somebody makes a mistake that results in accruing technical debt that the team didn’t know or make a choice about. This can be hard to track down and fix later.
• Inadvertent & Prudent: This is the “learn from your mistakes” quadrant. Here you recognize what you should have done so the mistake isn’t repeated in the future.

How do you reduce technical debt?

When you’re in debt financially, you want to pay it down as fast as you can to avoid paying too much interest. The same is true with technical debt. The faster you can address and fix the issue, the less technical interest you’ll have to pay in the form of adding more resources or delaying releases.

Here are a few things you can do to reduce technical debt:

• Make technical debt visible: Technical debt needs to be tracked in your project backlogs. Highlight the current state and progress of the work that is being done to reduce the technical debt in standup meetings, sprint reviews, reports, and so on. Be sure to track the tasks and estimated effort needed to pay off debt and commit to a schedule.
• Pay off debt incrementally: With the “snowball” method of paying off debt you pay incrementally from the smallest amount of debt to largest. For technical debt this means you would tackle the smallest and easiest fixes first and then move on to the bigger and more complicated ones.
• Prioritize: You can’t always begin with the easiest fixes. Some fixes might be more important than others. You’ll need to prioritize them to determine which need to be addressed first to meet customer demands.
• Be agile: If you use an iterative, incremental Agile approach to develop your software, then you should use that same approach for your technical debt. Create a user story for each instance of debt that satisfies your definition of done (the set of criteria and conditions that must be met to satisfy the customer).

Get buy-in from stakeholders: Sometimes stakeholders don’t see any reason to go back and clean up technical debt. The perception is that it will keep the team from working on new features and releasing new products, and it won’t bring in any immediate financial benefits. To get them on board, steer the conversation to the benefits of continuous improvement and product health.