For newcomers to the technology business, the notion of technical debt often sounds like a cop-out, an excuse for a team to deliver an unfinished or buggy product. And one can’t blame them: there are plenty of software developers who hide behind the concept when a project goes astray.
But the same can be said of a mechanic who removes a bolt by hitting it with a hammer until it breaks. Much like a hammer isn’t at fault, but rather the unorthodox mechanic, technical debt as a tool isn’t to blame when a developer misuses it.
Technical debt as a concept was coined by Ward Cunningham, one of the 17 authors of the agile manifesto. As he originally envisioned it, technical debt works like financial debt: you borrow money that you don’t have so you can invest in something immediately, and, when you pay back that money you add an interest fee, something extra for the person who took the risk of giving you the loan.
Bringing the metaphor back to software development, that loan usually comes in the form of time or resources. The team deploys an imperfect solution, but rather than leaving it as is, it comes with the implied promise that once data is gathered or a new approach is designed, there will be refactoring, which leads to a more refined product. That refactor is the interest fee.
Much like money debt, the more technical debt a project accumulates, the harder it’s to pay it back. As more and more things pile up, there is more refactoring to be done, more bugs to squish, more documentation to write, and more code smell to track.
A team that understands that technical debt is a tool and an investment uses it as a deliberate strategy to create a better product. But, like every tool, you get the most out of it when you follow the instruction manual. Unfortunately, there isn’t a tried-and-true method to avoid technical debt, but there are strategies that highly successful teams tend to follow.
Assess the Costs and Risks of Your Debt by Interacting With Your Clients
Information is key in decision making, so understanding the nature and scope of your debt helps you prioritize which parts to solve first. Define your debt around the following metrics related to the user:
- Costs: What is your technical debt liable for? By cost, we understand the loss of an opportunity, monetary gain, or time efficiency. Depending on your client’s business each loss could have a different priority. A business could be bothered with a slow process, but in a medical environment, it could literally prove fatal. Know your client and their needs
- Risks: If costs are a loss, a risk is the possibility of a detrimental occurrence. What could happen if you don’t pay back your technical debt? Much like costs, risks can be prioritized according to the nature of your client’s business. A great example of a risk is a security vulnerability that leaves the software open for attacks.
Understanding the client’s business and having a constant interaction with end-users is a good habit for a project manager who is trying to define probable costs and risks. Some consequences can be assessed before deployment, but others will eventually come forth as the software gets used.
Define the Nature of Your Debt With the Help of Your Team
On the other hand, understanding the nature of your debt can help you define a strategy. As a guideline, the Software Engineering Institute research team published a paper detailing 13 different kinds of debt, including:
- Architecture Debt
- Build Debt
- Code Debt
- Defect Debt
- Design Debt
- Documentation Debt
- Infrastructure Debt
- People Debt
- Process Debt
- Requirement Debt
- Service Debt
- Test Automation Debt
- Test Debt
Of course, it’s hard to clearly assess which debt takes precedence just by defining their nature. For that, it’s better to look at the costs and risks. Still, understanding where your debt lies helps you allocate resources efficiently and get a feel of what debts can be grouped together and solved in unison.
Team meetings, team sharing, and review sessions can help your teams identify each other’s debts as well as help them categorize it. In fact, a fresh set of eyes can uncover debts that inadvertently made it to the project. It’s also good practice to remind your teams that debts aren’t the end of the world. We are all humans after all, so turn risks into opportunities.
Keep Track of Your Debt and Put It Front and Center
Figuring out risks, natures, and costs isn’t enough. Every team should keep track of their debts as they arise and the project manager should keep a master list of all the accumulated debt. This may seem like the most commonsensical advice in the world, but you would be surprised to know that only 7% of developers methodically track technical debt.
That’s insane, as there is a negative correlation between tracking and the development costs associated with technical debt. The more you track, the less time and money you have to spend paying the debt later.
The two most common forms of tracking are backlogging technical debt tickets and carrying out static program analysis. A common mistake project managers make is to keep a separate list for technical debt instead of putting it together with regular tickets. The end result is that the debt list often gets forgotten until the end of the project.
Raise Awareness About the Debt
Much like a person ends up going over budget when they aren’t paying attention to the receipts at a shopping mall, a team that isn’t aware of the amount of debt accrued is more likely to go for further technical debt when the need arises.
If your system allows for it, a readily available counter that shows how much technical debt your teams have, or a literal list of all the tickets with their respective priority makes your teams more conscious of the cost of adding further debt to the project.
Also, inform your team of both the general risks of technical debt as well as the particular risks your debt could cause, help them be aware of the issues that they could be facing down the line.
Instill Good Practices That Reduce Debt
While it’s almost impossible to avoid technical debt, it doesn’t mean that you shouldn’t try it. Instituting good coding practices goes a long way to help reduce the possibility of having to rely on debt. Thus, you should:
- Go for abstractions and avoid tight couplings.
- Maintain a high percentage of code covering.
- Favor pull requests and code reviews.
- Refactor, refactor, refactor.
On a more general level, help your team members engage with one another and facilitate opportunities so that may share perspectives on each other’s areas. Like I said before, a fresh set of eyes is often what’s needed to find a better solution to a problem.
Also, consider adding technical debt as a metric of your software development, not as a hard ceiling. This should motivate your team to lower their current technical debt before incurring in more.
In Summary
Technical debt should always be a deliberate choice, but whether it is or not, debt can become an opportunity for a better outcome as long as the project manager and the team understand its associated risks and consequences and have the necessary tools to track it.
