What is tech debt, and why should you care about it?

Technical debt is a term coined by Agile pioneer Ward Cunningham to describe what happens when an engineering team must put the speed of delivery of software over the quality of a software solution. It means implementing a functional but less-than-perfect solution for now with the intention of going back and refactoring the code later (i.e., paying back the principle of the loan). If the team puts off refactoring, this may lead to issues that make it more difficult and time consuming to make changes or add new features in the future (i.e., the loan will accrue interest).

What causes tech debt?

There are many reasons a team may need to take on some tech debt. As Ward Cunningham discusses in an explanatory video, sometimes the team has to implement a solution that reflects their current understanding of a problem and later change the solution when their understanding of that problem improves due to user data. In other circumstances – when developing a new product in a competitive market, for example – the team might opt for a solution that's "good enough" in order to release the product more quickly.

Other causes of tech debt can be indicators of deeper problems on a team. For example, the team might be overworked or not have clear guidelines regarding product priorities. In other situations the team might have too broad a focus, working on too much at the same time. Martin Fowler developed the technical debt quadrant to demonstrate how debt can be taken on deliberately or inadvertently, prudently or recklessly, depending on the team's situation and choices.

The most common causes of technical debt are hard business deadlines that are not backed up by empirical data and evidence as to why these deadlines should be met. If a customer imposes a strict release plan and tries to cover too many features, engineering teams will try to do the most that they can as fast as they can, which often has a negative impact on the quality of the code.

Why should you care about technical debt?

Technical debt, when not addressed and allowed to accumulate, is costly in the long run because it makes it more difficult and increases the time necessary to make changes to the software. Tech debt impacts quality first, which in turn eventually hits all other metrics. For example, unaddressed tech debt can end up affecting the user's experience of the app, sometimes to the point where they can't get what they need out of the product and may look for a different option.

How should we address tech debt?

Agile practices put a lot of emphasis on managing technical debt, so a good Agile team stays on top of paying back the "principle" of the debt and making sure that minimal "interest" accrues. To ensure transparency, Agile teams should add tech debt items to the product backlog and not keep track of them in a separate document that's not visible to everyone. Most importantly, Agile teams should dedicate capacity to paying down tech debt every single sprint and include some refactoring items in their regular sprint planning. If tech debt is paid down consistently over time, it's much less likely to impact the product in a way that will affect core functionality or the user's experience. Customers can support engineering teams by allowing them the time necessary to find the right solution to a problem, ensuring quality and helping avoid or at least minimizing the need to rework the solution later.

Technical debt in itself, if taken on in a deliberate and prudent manner, is not necessarily a bad thing in the short term if it provides a functional solution. However, tech debt must be handled responsibly, and teams must have a concrete plan for paying it back. We hope this post helped you understand the concept of technical debt and the consequences of allowing it to accumulate. If you want to learn more about how our Agile teams work, you can check out our development process.