by Suzanne Erin on May 23, 2019

Just like good financial planning involves a strategy for paying off credit card debt or budgeting for home maintenance, good project planning involves setting a strategy to avoid and reduce technical debt. This post discusses methods to manage technical debt.

This is the second part of a two-part series. Visit the first part for an introduction to technical debt, its similarity to personal finance, and how it slows down development.

Your bank isn’t going to give you a contract for a credit card or a home repair loan without some strict rules about how they will be paid back. To keep technical debt from piling up, slowing you down, and costing you precious time, you need to develop your own system of accountability to manage debt.

First, avoid taking on debt that you don’t need. Using the credit card analogy, what are the terms for paying off this card? What if there is an emergency when you are already over-extended? What will this do to your credit score?

Likewise, consider the risks of taking shortcuts in software development: does rushing through something now provide enough business value to outweigh the costs of losing velocity down the line? Have you thought about the other risks? Code written in a hurry is harder to understand and navigate. It makes it harder to onboard new developers. It makes it harder to maintain a great user experience. How would problems impact your brand reputation? Does your business deal with money? Information that needs to stay secure? Is your site live in production? What are the potential consequences of bugs or breakage? Choosing to take on technical debt will increase risk for your product beyond just the impact on future velocity.

On the other hand, it is important to recognize that there is no truly debt-free software development. This is true even if you minimize risky practices. As you move forward, you’ll always discover ways that you can improve the underlying code. There will always be maintenance and upgrades that need to be performed. The trick is addressing them on an ongoing basis, so that their costs don’t compound.

There are a few methods to address technical debt. Consider using one or a few combined to manage your debt load.

• Leave code better than you find it.
• Prioritize paying off debt that slows you down the most.
• Budget time to pay off debt.
• Program in pairs.
• Plan ahead when taking on new debt.

This is known as the Boy Scout Rule. Boy Scouts leave a campsite cleaner than when they found it, picking up any litter they find. When a developer following this rule is working in an area, they take the time to improve the existing code at least a little bit. This way the code is always improving at the same time as value is being generated for clients.

The rate at which technical debt slows new development down is like a compound interest rate. A financial planner will advise you to start paying down the debt with the highest interest rate first. Likewise, identify the issues that are slowing down new development the most. Prioritize these as chores to complete in order of severity.

The biggest barrier to addressing technical debt is the pressure to keep finishing new features as quickly as possible. The business concerns that drive this pressure aren’t going to go away on their own. Neither is technical debt. Just like maintenance is a fact of home ownership, technical debt is a fact of software development. But you can plan for it. Budget regular buffers into your development cycle to account for unforeseen trouble.

One way is to set aside time. One client set aside the last three days of a three week iteration for developers to focus on refactoring. Rather than time, this could be in whatever metric you use to track effort, whether that be points, stories, or issues. Set a target amount to address per iteration. As needs are raised regarding refactoring, be sure to capture them in a way that can be tracked.

One of the benefits of pair programming is that two sets of eyes are continuously writing, inspecting, and changing the code all the time. It is code review by the parties who have the most investment and context for that part of the code. Two heads are better than one when it comes to coming up with the best approach to solving a problem or implementing a structure. More issues will be caught as they are being written, reducing the amount that become technical debt.

When you take on debt, you always agree to terms to pay it back. Likewise, If you agree to take a shortcut, ensure that there is a plan for going back to readdress it. For example, you go into crunch mode for an iteration to squeeze out features, then you know you’ll need to factor in more time to address road-bumps later. If you skip a step, like forgoing the implementation of error logging, make sure it has a place in the backlog. If you see that a new version of the language you are using has come out, then set a timeline to upgrade, even if it is a long term goal. The more you can commit to measurable milestones around these items, the better you’ll be able to avoid the traps of waving them off into the future indefinitely.

Carrying a lot of technical debt is risky, both in terms of lost velocity as well as other concerns like stability and user experience. Technical debt can be minimized through best practices, but it is inevitable that improvements will be needed on any project as time goes by. Therefore, it is important to have a strategy in place to manage technical debt as it comes up. Consider integrating strategies to address technical debt into your development process to minimize ongoing costs and risks.

Image by: Saad Chaudhry