Technical Debt: What It Is and 7 Ways to Avoid It

Technology teams are often attempting to speed up the delivery of a project or the delivery of a part of a project. In this process, unfortunately, mistakes are made and the work that has been expedited needs to be refactored. This is the result of placing more importance on delivering code and letting the quality of code slip a little bit. A scenario like this is often referred to as technical debt, synonymous with tech debt or code debt. Ward Cunningham, one of the authors of the Agile Manifesto, was one of the first to coin the term technical debt, explaining that some issues with code are like financial debt—it’s fine to borrow against the future, as long as you know you can pay it off.

It’s important to understand what tech debt is and how it impacts your team so you can meet organizational goals more productively and ultimately find success. This article will walk you through exactly what tech debt is and how it can cause long-term problems, elucidate the four types of tech debt, and give you some best practices for avoiding tech debt. 

• What is technical debt? 
• How technical debt can cause long-term problems 
• The 4 types of technical debt 
• 5 ways to avoid technical debt 

What is technical debt? 

In software development and engineering, technical debt (also known as tech debt or code debt) is the result of favoring speed over quality. In other words, it is intentionally prioritizing a quick delivery of code, even if the code’s quality is not up to standard. Tech debt is a term that is used frequently in technology organizations because it’s quite common to encounter bugs, legacy code, or missing pieces of documentation which all refer back to tech debt. Tech debt also includes the implied cost of any additional rework caused by using a temporary solution now, rather than using a more complex solution that will hold up long term. 

How technical debt can cause long-term problems 

Tech debt can cause long-term issues because projects end up decreasing in agility as the project progresses. When you take shortcuts to complete your code faster, you obtain code that is more difficult to maintain and to work with the long-term. This means that while you may achieve what you need to on a particular day and you get the code out in the short term, the code becomes more difficult to maintain over time and you end up paying a much higher cost later, in terms of both time and energy required to revisit and fix the code. In turn, tech debt affects productivity, workflow, and motivation as many employees will dread coming back to broken or unfinished code due to its time-consuming nature to fix. 

The 4 types of technical debt 

According to Martin Fowler, software developer, author, and international public speaker on software development, there are four types of technical debt that each belong to a quadrant: 

• Deliberate and reckless
• Deliberate and prudent
• Inadvertent and reckless
• Inadvertent and prudent

1Deliberate and reckless

In the deliberate and reckless quadrant, you are fully aware that you are making a design choice that will undoubtedly create tech debt. If you find yourself in this quadrant, consider the long-term impact of the decision, if you’ll track the tech debt level as it continues to be incurred, and if you have some kind of a plan to pay off this tech debt (in which case you should also consider the budget that you can pull from, if applicable). When you don’t give time to these considerations, the tech debt goes from more deliberate to more reckless. 

2Deliberate and prudent

Deliberate and prudent tech debt is the result of a carefully weighed situation, where the person making the decision takes the time to measure the risks versus the rewards of the technical debt. In this situation, the decision maker creates a tangible plan to address the consequences of the tech debt they’re incurring. The deliberate and prudent approach always considers the worst-case scenario so the team is prepared to tackle it, caring about the future consequences and figuring out a way to overcome them effectively. 

3Inadvertent and reckless

The inadvertent and reckless quadrant refers to the things you should have known, but didn’t at the time. This often results because of gaps in knowledge or experience. If you find yourself in this space, next time, be sure to take extra time and care to endeavor to find solutions and answers from more experienced team members. If your organization has access to industry knowledge and best practices, you should be able to avoid this kind of tech debt, so do your research and dig for the answers you need to avoid being ignorant and reckless. 

4Inadvertent and prudent

Inadvertent and prudent tech debt means that the decision maker has truly done their best to leverage industry knowledge and engaged in the right research. Despite these efforts, including the investment of the decision maker’s time into continuous learning and skill development, tech debt occurs because there are some kind of unforeseeable bugs or missing documentation that you’ll need to come back to. Nothing can really predict this kind of tech debt, making it the most difficult one to overcome. The best approach is to maximize the learning opportunity as quickly as you can. 

5 ways to avoid technical debt 

• Calculate your technical debt ratio (TDR)
• Maintain code quality 
• Keep track of your new bugs vs. closed bugs
• Distribute code ownership
• Keep an eye out for high churn

1Calculate your technical debt ratio (TDR)

One way to avoid technical debt is to calculate your tech debt ratio (TDR), which gives you the overall future cost of your tech debt, whether the cost be time or the use of another resource. 

The formula is pretty straightforward: 

(Remediation Cost ÷ Development Cost) × 100 = TDR

Remediation cost is calculated as a function of the code quality metrics and the development cost is the total number of lines of code required to build a product or feature, divided by the average resources expended per line. The outcome of the equation gives you a simple ratio which tells you how much time or resources you’ll need to use to recover from the tech debt. 

2Maintain code quality 

Next, you want to ensure you’re maintaining the quality of your code. When you notice that your code is becoming increasingly complex, this is a sign that your tech debt is growing. Code quality is directly related to several metrics on which you want to score as low as possible. These metrics include the cyclomatic complexity of the code, class coupling, number of lines of code, and the depth of inheritance. 

3Keep track of your new bugs vs. closed bugs

Make sure that you’re keeping track of your new bugs versus your closed ones. You can view every bug as a tiny piece of tech debt that slowly but surely adds up. Tallying your bugs, new and old, will help you and your engineering team calculate how effectively you’re managing your tech debt. By keeping this tally, you can then identify if your new bugs are outnumbering closed bugs, which means you definitely need to be making some changes so your tech debt doesn’t keep growing. 

4Distribute code ownership

Effectively distribute code ownership. When you have too many employees working on the same task, chaos ensues. Distributing code ownership is about finding a healthy balance in not assigning too many people to a task, but also not leaving one person with full ownership and responsibility over a task. Take some time to identify who and how many people have worked on which projects so you can decide who would be the best fit, and on average how many people are required to get the job done. Assigning action items in Fellow with an assignee and a due date avoids any confusion as to who is responsible for what. And as a manager, you can see your teams action items to have a better understanding of how projects, code, and work balance is going! 

5Keep an eye out for high churn

Make sure that you’re keeping an eye out for high code churn. This is a metric that counts the number of times a specific line has seen code deleted and replaced or rewritten. Churn is inevitable, especially when you’re working on a new feature, but after you and your team have launched a new version and fixed the identified bugs, the churn should start to lessen pretty quickly. High churn over a long period of time is a red flag to which you need to pay attention. It likely means that there are mistakes being made with each iteration or that the team is using quick fixes to temporarily resolve issues. 

Parting advice 

Technical debt is pretty much inevitable if you work in software development. What’s important is the way that you and your team manage your tech debt so the business can thrive. The approach you take to the management of your tech debt is really important and will depend on which of the 4 quadrants your tech debt falls into. For this reason, take the time to really understand how and why you have incurred your tech debt so you can find a suitable solution. As you and your team continue to experience different kinds of tech debt, you will undoubtedly learn how to manage it more effectively. Be sure to revisit this article for a refresher when needed!