Developers Share How They Prevent and Manage Technical Debt (Part 2)

Plenty of people have written about technical debt. They might be discussing it in the context of improving velocity, code churn, code refactoring, or it might just be an item on a very long to-do list that never gets prioritised. We put out a call out for real-world experiences of what helps when it comes to reducing technical debt and received a huge number of responses from devs across a variety of sectors. In the previous article, developers told us about their technical debt horror stories. Here’s what they had to say about how to manage and prevent it:

Treat technological debt as a tool rather than a scourge

“Technical debt, like financial debt, is more likely to become an issue if you ignore it or act as if it doesn't exist. Instead, accept it and regard it as a method that needs constant attention and maintenance.

The first step is to accept that certain technological debt will still exist and that this is a healthy thing. Spending time attempting to eliminate technical debt could mean you're not providing enough value to your customers while they're trying to solve new and creative problems.

A strong rule of thumb for sorting “good debt” (the technical equivalent of a manageable mortgage, for example) from “bad debt” (the technical equivalent of excessive high-interest credit card debt): The key is to carefully balance the key trade-offs that provide the most value to customers while incurring the least amount of debt. Also within the same organisation, this type of evaluation can differ."

• Jason Mitchell, Chief Technology Officer at Smart Billions

3 simple tips to tackle technical debt

“Here are my 3 top tips to tackle tech debt:

1. If you are an agile team, have a technical debt story to be tackled in a quarter. Now you may not get to all the debt but minimise it to core objects which can be handled in a sprint and slowly level it till it is done.

2. Have technical debts in the fourth quarter where business wind down and have them completed at that time.

3. Leverage your vendors to do the technical debt instead of your employees. The reason is sometimes your admins and architect can focus on the regular needs of your business and your vendors can do the technical debt independently and get it done with minimal supervision. So the bottom line is cadence on technical debt, resources to tackle them and go at it in small chunks to solve future leaks.”

• Buyan Thyagarajan,  Salesforce MVP specialising in Salesforce CRM and Marketing Automation, Eigenx

Embed technical debt management into the company culture

“As part of our company's culture, we deal with tech debt with a joint code review. This helps knowledge move across the organisation and potentially avoids making the same mistakes for the next features and products developed within the company.

We have created a full “Definition of Done” flow, where even if you make technological compromises along the way and as part of the design, they are logged immediately so the product or feature is not DONE until we have handled them (even if that means we are eternally in beta phase).

We have found that dealing with infrastructure is another great method. If we are fixing a tech debt, and the cost of making it solid infrastructure as part of the platform (for the next services and features) is not too high, we will choose to do so.

Additionally, we have a few tech debt enthusiasts, led by our lead engineer, who keep this conversation above the ground at all times.”

• Aviad Mizrachi, CTO & Co-Founder of Frontegg

Documentation is everything 

“Since IT can be such an effective way to help improve a business, losing out on the capabilities that an effective IT team provides can be really damaging to a business. Our primary tool in helping with both eliminating technical debt and keeping it gone is solid documentation. Training our technicians to always document every element of a ticket and any oddities and configuration details not currently documented that they see in an environment before moving on allows our technical leads to having a much better idea of the state of our customer environments, and therefore a much clearer idea of what the issue could be when something goes wrong.

At the end of the day, better documentation and cleaner environments allow more to be done by IT with less labour, both in the reactive sense of fixing issues and in the proactive sense to help develop your business.”

• Channing Norton, owner, PC Solutions

Product owners can help prevent technical debt

“As Product Owners, you can aid in the prevention of new Technical Debt. If features that are not used by users/customers are not maintained at the same level of quality as the rest of the Product, they can accumulate Technical Debt. Recently, one of my teams discovered a functionality that none of our previous or current customers uses. Worse, there were no corresponding automated checks. Not only was it causing difficulties during the coding process, but considerable time was being squandered by manually regression checking it.”

• Chana Charach, Chief Financial Officer at Income.ca

Make technical debt a priority in open source culture

According to Justin Dorfman, Open Source Program Manager at Reblaze, what has helped is “not being a gatekeeper and or control freak. All code is disposable and we should never get attached to any of it.

For organizations, culture is very important. Too many developers work in places where “there’s never enough time to do it right, so later we’ll have to do it over.” For individuals, attitude is very important. Developers tend to be very independent, and we’d rather not participate in formal code reviews, pair programming, and so on—but those practices can help prevent a lot of technical debt.

Technical debt is often a hindrance to performance. When you get rid of it, the code can run faster and better. And I find that there’s a personal reward too. In open source projects that I’ve started, once the projects have caught on, new contributors come in. Often they will take my code and, before it could turn into incurable spaghetti code / technical debt, they will rewrite it and optimise better than I could have ever imagined.

Curiefense, is Reblaze’s latest open source project:

“Even though it’s only ~6 months old, we are already fixing tech debt, such as rewriting some of the code in Rust for better performance and security. What’s great about open source is that our practices, roles, responsibilities, and tools are all public. The fact that our users can open an issue (on GitHub) so we can then address and fix it in public clearly shows who, what, why, and how we work to minimise technical debt...The tools we use besides GitHub issues to help us fight tech debt are CI/CD, Bots (Dependabot, CodeQL), and following best practices.”

• Justin Dorfman, Open Source Program Manager at Reblaze 

Mention Technical Debt in Stand-Up

"If you're working on something that appears to have the potential to generate technological debt in the future, it's worth noting during these stand-ups. Someone else on the team may have an idea for resolving the issue without incurring debt. At the very least, it alerts the project manager to the possibility of future attention being required."

• Pooneh Ramezani, CEO of Dr. Brite 

Add a Project to Your Product Roadmap

"The product roadmap is a high-level document that communicates what tasks to occur in order for a product to achieve its vision. Typically, the types of projects that appear on a roadmap are those that address the needs of your product's end users. There are several instances where you can argue that adding a technical debt project to the roadmap is essential. This is the case where a considerable amount of time is required to complete the solution, more than a few weeks of work will provide. Similarly to creating a ticket in the backlog, once a project is added to the roadmap, it should be reviewed in conjunction with all other projects to assess its priority."

•  Dusan Stanar, Founder & CEO of VSS Monitoring

Adjust Your Definition of Done

“If you write tickets properly, each one will have a description of completed. The term over refers to a set of tasks that will be valid until the ticket is resolved. Once all is verified, you can close the problem. Writing an effective description of ‘finished’ requires ability. 

A comprehensive definition of done should include the activities necessary to resolve technical debt. For instance, if you're still using legacy payment provider code and have a ticket open that includes some payment provider code, the concept of done could include updates to payment provider API version 3. Including tasks in your concept of finished will lengthen the time required to complete the ticket, but once completed, you won't have to worry about old code slowing down development work.”

•  Tony Kelly, Founder & CEO at CameraGroove

Choose a Flexible Architecture

“I still emphasise the importance of good architectural design. Software evolution is the focus of today's development. And architecture that needs refactoring and isn't flexible enough to accommodate changes would be a costly debt to repay.

As a result, we at TRGDatacenters use easily scalable architectures, such as microservices/container-based architectures, to easily expand them at the start of an agile iteration for new features planned for release.”

• Eric McGee, Senior Network Engineer at TRGDatacenters

Understanding the problem is the key to developing a solution

Stepsize enables companies to gain real actionable insights into their technical debt. With our product, engineers can track debt directly from their workflow (code editor, pull request, Slack, and more). Stepsize automatically picks up important context like the code the debt relates to, and engineers get to quantify the impact the debt is having on the business and the risks it presents (e.g. time lost, customer risk, and more) so that you can prioritise it easily. 

Our core product is available for free to all teams and our debt calculator gives you a starting point to determine where to focus your energies.