Tech Debt: What Is It and How To Deal With It

All teams have to deal with deadlines, budgets, and other constraints when creating a product.

These parameters all impact decision-making and lead to tech debt being introduced. Sometimes tech debt comes from having to push out an update quickly. Other times, it can come from a lack of understanding or experience. Regardless of what the cause is, teams need a way to deal with the tech debt so it doesn’t slow them down too much in the future. Understanding and preparing for tech debt allows teams to push out updates faster, keep their code base in a state that is easy to work with, and have a better idea of the challenges they will face in the future.

But What Is Tech Debt?

Tech debt is future work resulting from decisions made during feature development and bug fixes. It is the tradeoffs we make in order to create a product. Sometimes the tech debt can be quite large; maybe a system needs to be completely re-architected because the current implementation cannot handle a very large user base. Other times it can be something simple like refactoring a class or function once it needs to be expanded.

Defining, Identifying, and Measuring Technical Debt highlights 13 types of tech debt:

• Architecture Debt
• Build Debt
• Code Debt
• Defect Debt
• Design Debt
• Documentation Debt
• Infrastructure Debt
• People Debt
• Process Debt
• Requirement Debt
• Service Debt
• Test Automation Debt
• Test Debt

For a more in-depth discussion on this topic, see Towards an Ontology of Terms on Technical Debt, which the above blog post is based on, but exists behind a paywall

Where Does Tech Debt Come From?

The short answer is every time a product decision is made, tech debt comes with it. That decision can be about prioritizing a new feature, updating the design, changing the back end, etc. While that might sound bad, tech debt is not necessarily a bad thing since systems should evolve as needs change. A system can be made to handle a small user base to save money, knowing that it will have to be updated as the user base increases. The debt caused by that decision would likely be an architecture debt. If the system is changing and you know you will need to update the documentation, then you have documentation debt.

How Can We Manage Tech Debt?

The first step is to try to better understand what the consequences of your decisions will be. Knowing what the tech debt is ahead of time allows you to plan for it. Depending on your role, you should only have to worry about a subset of the 13 types of tech debt. Sycorax, The team I am on, came up with the idea of holding a State of the Base every few months following major milestones.

State of the Base

The Sycorax team was about to begin work on a new project, and the developers wanted to be better prepared. While looking back at what we had already made and how to apply the lessons we learned, we decided to list out some of our complaints and pain points with the first project. We came up with this concept specifically for dealing with code, documentation, and architecture debt, but it can be tweaked and applied to any kind of tech debt.

We created a document to record some of the pain points and set time aside to discuss them and how to improve the issues or avoid them in the future. We eventually settled on a simple table with 5 columns:

The developers are able to add to this document whenever something they want to improve or deal with comes up. This helps keep us on track with feature work while creating and pointing new tickets, reviewing PRs, or just working on parts of the code base while not letting tech debt fall through the cracks. The above table has two examples, we determined each to be pretty straightforward, but the priorities differed. Making our logs better can help us diagnose a bug for our customers. The sooner we find it, the sooner we can solve it. The second one is purely to make writing tests a little easier, it might not be worth changing our existing tests, but it’s something to keep in mind for future tests.

Benefits of State of the Base

• Work valuable to the team remains available even when epic-specific tickets might be blocked
• Easy to see all non-feature-related improvements prioritized in one place
• Prevents side-tracking during technical discussions and helps keep the team focused
  • This benefit extends to PRs when a concern arises that is out of scope and should be staged appropriately for follow up
• Encourages ownership by ensuring space will be made to review all ideas for improvement
• Encourages consistent improvements in code maintainability

This Sounds Great, but We Don’t Have Time To Add More Work…

Tech debt will add more work whether you plan for it or not. The system can no longer handle the traffic, the “quick fix” had side effects you didn’t plan for but now have to deal with, etc. Tech debt will come for you! Understanding and planning for it allows you to deal with tech debt earlier and potentially faster than when the issue pops up and breaks production. This doesn’t mean you need to constantly be trying to deal with the tech debt at the expense of enhancements to the product. We write up all of our State of the Base tickets and keep them in the backlog for the developers to pick up when time allows. By adding the lift and priority columns, we are better able to frame the tickets to our PM. Taking time to discuss the tech debt and determine what needs to be fixed versus what would be nice to fix allows the team to explain why the changes are required. This is especially important when proposing things that do not change the user interaction, like updating the database schema.

Conclusion

Whether you decide to adopt State of the Base or come up with your own methods, understanding and planning for tech debt should be part of your decision-making process. Knowing what issues will arise as a result of your decisions helps you make better decisions and be better prepared for changes that will have to happen in the future.

Martin Mammel

Marty is a software engineer at FloQast. When he is not working you can usually find him on a golf course, walking his dog, or reading a book.