Clearing technical debt is perhaps the least glamorous part of an engineering team’s business, albeit just as important. So how does one balance working on features and tackling technical debt? Prioritizing one over the other can create potential crevices in your climb to the top. Investing too heavily in feature work can lead to systems with cascading failures while investing more in technical dept work can impact the sense of progression and overall spirits of the team. 

It seems like a catch-22, but is it?

Blanca Garcia Gil, Principal Systems Engineer at BBC, moderated our panel discussion to address this. The panel featured James Smith, CEO and founder of Bugsnag, Maude Lemaire, Author and Staff Software Engineer at Slack, and Rodney Cobb, Principal Software Engineer at Remine Inc.

This panel of industry experts sat down to dissect the ideal time and manner of working on technical debt, as well as identifying the time to stop. It tackled issues such as planning ahead, prioritizing technical debt work and identifying red flags of larger problems, all while keeping your team in the know-how and empowering them to perform better. 

Defining Tech Debt

James Smith defines technical debt as intentional and unintentional choices that need to be confronted at a later date but doesn’t approve of the bad rep it carries, and while he admits that there are consequences, he considers it a trade-off for in the moment productivity. Maude Lemaire doubled down on the same thought and also added that often the debt is incurred due to a change in requirements, therefore it is unpredictable but necessary for the broader vision. Rodney Cobb highlighted the importance of consistent and coherent communication between the development team and the product team to both limit the debt incurred as well as to make it worth your team’s while. 

Technical Debt and Legacy Software

Our panel also discussed the emotional toll that technical debt can take on an engineering team, where other teams might not understand the frustration and distress the developers feel over accidental or incremental bit rot. James Smith highlighted how over time even a perfectly accurate file of legacy software can evolve into technical debt through bit rot, which is an unintentional but organic technical debt that most organizations inevitably accrue. While trying to stay within the paradigm, bit-rot can stack up and go unaddressed through several refactoring repos. He encouraged leaders to keep an eye out for the trailing symptoms of this.

Addressing Technical Debt with Top Management

Maude Lemaire addressed how Slack is an anomaly in how the organizational leadership prioritizes addressing technical debt and acknowledged that it’s not the same for most others. Through her years of experience dealing with stakeholders, she shared a few tactics she had learned. Maude suggested asking stakeholders or top management what they are most concerned about six months or a year down the line and framing tech debt projects in that lens. Talking to broader teams is great for discovering and zeroing in on problematic files. Quantifying and measuring the value of addressing tech debt is also key to convincing stakeholders to prioritize it. 

Convincing Engineers to Address Tech Debt

A tsunami of technical debt can burn out even the brightest and most resilient developers on your team. This would lead one to address the most pertinent task: identifying and sustainably tackling technical debt. One inalienable aspect of this is to have the broader team on the same page when it comes to the importance of minimizing and quickly clearing technical debt. Rodney Cobb does this by asking his team if they want 20% of their time back. In his experience, by framing time as a quantifiable resource, he’s able to drive the vision home with his entire team. He encouraged conversations with engineers who are intrinsically creative problem-solvers on defining the path to clearing tech debt. 

Does the Maturity Stage of a Company Play Into Handling Tech Debt 

As an ex-software engineer and current CEO, James Smith believes that younger companies have the space to fail and they should do it fast so that they can benefit from the experience that comes with it. But for older companies, the cost of failure is too high and they have a lot to lose by collecting technical debt. When a mature company has others depending on them for an optimized tech stack, having bones in their plates can quickly turn catastrophic. 

Key Takeaways:

• Finding trends in questions and comments in code as a way of identifying potential or existing technical debt. 
• Documenting and measuring as a means of identifying the priority placement of technical debt
• Avoiding technical debt by making a deliberate plan at the beginning  and then sticking to it
• Creating meaningful milestones on the path to refactoring as means of motivating your team
• Accurately compartmentalizing and segregating the necessary and the fluff when tackling technical debt
• Identifying the hidden opportunities that may exist in your technical debt by shaving off the right areas