As software development moves faster, the demand from users has become a stream of ideas that businesses try to leverage in order to gain a competitive edge. As a result, the turnaround time for features has decreased. Developers are having to make concessions on writing clean, manageable code in order to get features into the hands of users as quickly as possible.

As the apps – and the services that make them up – grow more complex, the skeletons in the closet become harder to ignore. ‘Technical debt’ is a term coined by Wade Cunningham to help describe these ‘skeletons’ that prevent engineers from actually working on solving business problems. Instead, the skeletons force them to ‘pay down’ the debt that’s been accumulated from previous development efforts.

Technical debt can be a point of contention depending on the development culture of a company. However, the reality is that you’ll have to make decisions on how to tackle it at some point. Whenever this day comes, having a plan everyone can get behind is going to be vital in making progress toward getting rid of those skeletons in the closet.

In 2014, the Software Engineering Institute published an abstract describing the different types of debt teams accumulate. No team has to adopt all, or any, of these categories but it provides a solid framework for beginning to make sense of the debt that has already accumulated. Depending on what’s used as the project management tool of choice, a way for these categories to show up is through the use of labels or tags to keep track of technical debt in the backlog.

Making debt trackable in the backlog is great for making the debt as real as the other tasks that are needed to deliver business impact. Plus, being able to run reports against the technical debt accumulated in the backlog is a tangible way to sell others on prioritizing time towards it.

Allocate some time to talk

Even with as little as 15 minutes per sprint, a team can go from invisible debt accumulation to having a backlog full of visible and categorized technical debt that can be used to help schedule efforts towards paying it down.

Assuming there’s a retro/review every sprint or milestone, a great way to start tracking debt is by having a 10-15 minute segment during these conversations to talk about debt accumulation. From the concessions made, to what a potential solution could look like, converse about how the technical debt is showing up in the codebase. Place this info as a backlog item and label it with one of the categories created beforehand.

Prioritize your efforts

As the backlog begins to build up with technical debt, start budgeting some time at the beginning of the sprints or milestones to tackle it. The priority can be based on what’s going to help clear the runway for upcoming features, degradation of services from old debt, or even debt discovered from a recent issue which may have appeared in the form of an incident. The direction the team decides can change with every sprint, however, ensure you are committing at least one backlog item to the capacity of the team’s sprint. 

Tackling debt collection in this way ensures there’s a focus on cleaning up debt that’s going to give immediate returns. Sometimes it’s easy to get lost in trying to pay back debts without tangible ways of measuring if it’s not worth the effort. However, staying focused on immediate wins, in the beginning, can give a team and management enough satisfaction to consider scaling the efforts in the future.

Consider the time committed to the capacity of the team’s efforts as ‘paying down the balance’. A team can just stick to paying the minimum, or they can commit more time to free themselves of debt faster, giving them more runway to work with in the future. 

Leverage debt to create opportunities

Winston Churchill once said, 'Never let a good crisis go to waste', and it rings true for every development team. Whether you’re here because something broke and it’s making the team evaluate how they would have caught an issue sooner, or the debt has accumulated so much it’s creating terrible developer experiences, all reasons are valid for taking action. 

As stated earlier, debt isn’t black or white, but understanding when it can be good is pivotal for leveraging headaches into opportunities. One of the harder things to do as a developer is selling others on the idea of paying debt back. However, when there’s a list of backlog items pointing to issues that are poking their head out in the form of performance degradation or bad end-user experience, this can be an opportunity to look at the documented technical debt that could be causing the issues.

Celebrate even the small wins

We’ve been able to do the following:

• Categorize our debt; 
• Create consistent conversations around accumulating debt;
• Fill out our backlog; 
• Schedule efforts towards paying down the debt;
• Leverage the debt and create opportunities to update or refactor code, therefore improving developer and user experience. 

That’s a lot of work so make sure to celebrate these wins whenever any milestone is reached! 

It’s easy to gloss over the work teams do to clean up or improve things that may not yield immediate impact to the business, but it’s important to highlight when persistent efforts are actually seen all the way through. Without any round of applause at the end of these efforts it’s easy for teams to fall back into the same dirty habits that made them put together a plan to improve things in the first place. Keep others motivated with small celebrations along the way and don’t let others' hard work go unnoticed in order to maintain your momentum.

Whether it’s a new developer or a seasoned vet, technical debt is a reality everyone has to deal with. Understanding how to properly tackle it is going to save everyone a lot of headaches down the road whenever that debt comes knocking.