3 Ways to Manage Your Technical Debt

Technical debt has gained popularity over the last few years as a metaphor for the accumulation of things that should be changed, replaced or removed in an application. Any organization with more than a few lines of code in its repositories has some level of technical debt that needs to be managed.

But unlike the financial debt that provides the basis for the metaphor, technical debt is far harder to quantify. Even defining what constitutes technical debt in a particular organization can be elusive, let alone assigning an effort or dollar value for addressing it.

We usually create technical debt for the best of reasons. Most often, we’re in a rush to make a deadline. It’s easy to tell ourselves, “We got it working, even if it is a little ugly, now we need to move on to the next item so we’ll come back and clean that up later.” But in many organizations, later never comes, and we end up with something that isn’t as good as we know it could be.

Unfortunately technical debt rears its ugly head at the most inopportune moments, like during a funding round or acquisition, or a large customer deployment.

All organizations that develop software, whether or not you’re a software company, accrue technical debt, and in some circumstances our actions add to our debt. Every time we copy and paste a block of code and make one little change, or use a library for something other than its intended purpose, we ring up another amount of technical debt.

At other times, technical debt can accrue through inaction. Ignoring compiler warnings, failing to document code, or sticking with a technology platform longer than we should can all make a codebase more difficult to live with. Soon enough, your state-of-the art code has turned into a confusing jumble of workarounds.

The best way of dealing with this situation is to avoid it in the first place, but through our work with countless organizations, we’ve identified three important ways that software development leaders can help keep their technical debt under control.

Set Your Standards

Having a strong set of coding standards, use of frameworks and third-party libraries, and good test coverage will help your team maintain consistency and structure in the code. All team members should be empowered to hold each other accountable to these standards, but as the manager, you’ll need to take the lead in establishing these standards if they’re not already in place and enforcing them with an ongoing process of code reviews.

Some team members may grumble, but eventually most will see the utility of adhering to a defined set of standards.

Describe Your Technical Debt

At some point, your team may decide that the best course of action is to accrue a debt in order to reach a goal. When that happens, you should add a corrective action to your backlog. The only way your team will remember to go back and address these things is to record them.

Having technical debt backlog items also allows you to estimate the amount of time and effort it will take your team to address the debt. You may also want to create a backlog item type specifically for technical debt to distinguish it from the typical user stories, chores, and bugs. This is a useful technique for reporting and communicating the magnitude of the issue.

Identify Your Priorities

Once you’ve described your debts, you’ll only pay them off if you give your team time to work on them. The best way to do that is to include technical debt items with your other backlog items and prioritize them together.

If you’re following a Scrum methodology, your team may need to educate the product owner on the need for these items. Your developers must also be prepared to advocate for their items in terms of the business value they’ll deliver. If there’s no business impact (like increased quality or development efficiency), then why is this item in the backlog? Prioritizing your technical debt alongside other backlog items will help you start to control it.

While you shouldn’t attempt to eliminate technical debt in one shot, be sure you don’t acquire more technical debt than your team can handle. You should also be mindful of giving your team the adequate time and space to address the issues they know exist in the code. Every team learns new and better ways to do things as they go, and the people who spend their time coding know what makes a particular codebase difficult to work with.

Empowering your team to address those issues will result in better products, happier users, and less-grumpy coders. You’ll also be better positioned to see an increase in team velocity and overall employee morale.

This post originally appeared in the November 8, 2016 issue of VentureFizz.