Apps + Coffee Connection: A fresh look at cleaning up your technical debt

This blog is part of a series that delivers insights from the monthly meetups of Bugsnag’s Apps + Coffee Connection (ACC) community.

Did “technical debt cleanup” land on your resolution list for 2022? Are you feeling some uncertainty around how to approach tech debt within your organization? You’re in luck: the December ACC meetup tackled this very topic, which is viewed as a universal challenge for engineering teams. Not only did the lively discussion deliver insights into the different types of technical debt and why it’s important for engineering to take the lead, but participants also provided numerous strategies and approaches for addressing it and ensuring its inclusion on product roadmaps.

Understanding the forms of technical debt (spoiler: not all are bad)

Technical debt is a normal part of the development process and something developers deal with every day. The quick-and-dirty definition is that it’s code that needs to be reworked or deprecated, which sounds like a bad thing. And sometimes it is, especially when tech debt results from poor coding.

However, not all technical debt is bad. As one participant pointed out, “There’s a negative perception of tech debt, but if you think about it in a financial sense, for example, it’s not a bad idea to take on debt to buy a house. However, it is a bad idea if you don’t have a long-term plan or the ability to pay it down.”

The same holds true for technical debt. It can be considered “intentional” if fast coding is used in order to get a new product or feature out the door and test its viability in the market. This scenario is usually a joint decision between Engineering and Product or business leaders, who have decided together to spend less now, with full recognition that they will spend more in the future—if and when the value of the product or feature is proven. Certain factors, including limited early funding or a well-timed market opportunity, can require speed to be prioritized over quality in the short term.

“First, there are things that developers know about when they create a piece of code that they know will need to be cleaned up later. The roadmap needs to capture that data and put it somewhere so that it can be worked on in the future,” one participant explained. “On the other side, there’s also the technical debt that happens due to the march of progress. Every piece of code we create has the potential to become debt in the future. Any technology you’re picking now is going to be obsolete and outdated sometime in the future.”

It’s also worth noting that technical debt sometimes occurs when a team inherits an application or a feature set through an acquisition. This scenario can be challenging because coding may have been done with a different style guide, which can make it difficult to assess tech debt and determine where to make investments over time.

Communicating the need to address tech debt

Who owns technical debt? One participant said unequivocally, “Developers are your first line of defense on technical debt. It really can’t come from product management, at least for the hands-on piece. A lot of tech debt needs to come from engineering.”

While engineering may drive the conversation and push for development time to address tech debt, prioritization within and across the organization is also critical. “It’s very important for a development team to see that you’re paying that tech debt down,” a participant explained. “If the developers think, ‘Every time I mention tech debt, it goes into a void and never gets worked on,’ you’re not incentivizing developers to report tech debt and catalog it.”

Part of the struggle with tech debt is explaining to non-technical people exactly what it is. “When you talk to stakeholders or Product, it’s Greek to them,” a participant stated. “We as engineers and engineering leaders need to figure out better ways to explain what we mean and relate it to something meaningful from a business perspective, such as how it impacts our end goals and strategies.”

One participant promoted the idea that developers should focus on the impact of technical debt, rather than the sheer amount of it. This strategy brings to light the benefits of addressing it, such as improving productivity or eliminating inefficiencies. Another participant chimed in, “One thing that helped us was to put a hypothesis out there—by doing this, we think we can achieve this—and then timeboxing it. For example, if we spend x-amount of time clearing tech debt, we can improve performance by x-percent.”

Transparency through data was another suggestion. “You need to make the reasoning, or the ‘why,’ much easier to sell,” a participant stated. “If you’re doing it based on data or outputs, it makes it much easier to explain to non-technical stakeholders and moves the conversation away from ‘developers want to spend time rewriting code they don’t like,’ to making prudent decisions based on the data itself.”

And, if talking-the-talk helps, one participant shared another financial metaphor that might resonate with stakeholders: “Technical debt accrues interest, and it’s something that needs to be paid down over time. You can’t ignore it. That interest will continue to accrue. So, if you take shortcuts with your first deliverable, it becomes more expensive over time and stops you from delivering other things.”

Strategies to gain support and attack tech debt

The general consensus amongst participants was that technical debt should be addressed on a regular basis. In order to do so, companies must have a clear understanding of what tech debt is and how to collectively pay it off over time. “Creating trust across the entire organization as to how we deal with tech debt is one of the most important things,” one participant stated. “Tech debt becomes more expensive if we don’t invest in it. If we defer now, do we trust ourselves to address it in the next cycle?”

First and foremost, technical debt must be recorded and cataloged in order to understand the scope and to have the data to determine what to focus on. One participant provided a warning and recommendation: “We used to have a separate tech backlog, but that didn’t merge well with the product backlog, so we brought them together. Now we use the 80/20 rule, with 20% of our capacity focused on tech debt. It’s built into our sprints. We are also starting to build dashboards that give us a better indication of the accumulation of tech debt versus the amount that is being deprecated.” 

Another participant promoted the use of static code analysis tools, which can help stop tech debt before it happens and promote a quality approach to delivering software: “You can eliminate technical debt upfront by having these tools in place for when you make a commit, but there must be buy-in to use these tools. I recommend working them into build pipelines as soon as possible and refusing code if it doesn’t meet your guidelines.”

In addition, one participant mentioned Martin Fowler and the use of hot spot analysis. The idea is that, if you don’t know where your technical debt is exactly, you can analyze which parts of the code are changing frequently and rate it against complexity, which should lead to a return on investment for refactoring that component.

For best results, take a measured and consistent approach

Attacking all tech debt at one time may sound like a developer’s dream, but participants referred to this opportunity as “a really tough one to sell and get support for” and “very rare.” Even if velocity is hampered by tech debt, numerous challenges exist to spending a development team’s time on a complete rewrite. For example, there are complexities around keeping customer and partner contracts, coupled with the economic hit that the company will take by pausing forward progress.

“I’ve never seen a tech debt project work in practice where a company commits to spending months tackling only tech debt,” one participant stated. “After all, how can you prove that you won’t have an equal amount, or even more, technical debt at the end?”

Rather than go all-out on technical debt, the general consensus was that it’s best to take a measured approach. One participant stated, “Technical debt is something that comes up almost on a daily basis. If there’s not enough time to focus on tech debt, it just keeps piling up. We need to ask, how can we do more on an ongoing basis so that we don’t continue to accumulate debt and it becomes insurmountable?”

“Tech debt needs to be built into the culture of how you approach delivering software. You should be able to prevent unintentional tech debt if you have good processes, good automation, good tooling, and good leadership,” a participant stated. “Then it’s really about dealing with intentional debt and having transparency where everyone knows you’re doing something that isn’t quite right, but you’re doing it for the right reasons. We want to get that release out the door, and we’re going to pay off that debt.”

One participant summed it up by stating, “You have to deal with the entropy of software. That’s natural. You also have to continuously deal with that intentional debt, but it’s something we can easily refactor once we prove out the hypothesis. However, there is no end to dealing with tech debt.”

Interested in participating in conversations like this? Join the monthly discussions with the Apps + Coffee Connection community by registering here.