Technical debt isn’t inherently bad – used properly, it’s an effective tool for shipping code faster and more frequently.
However, as with financial debt, you’ll eventually run into problems – potentially serious ones – if you ignore your existing balances while continuously borrowing more and more.
“Like financial debt, tech debt is not always bad, but we must be smart about it,” says Travis James Fell, product manager at Hypori. “Incur tech debt in light of the business benefit, understand other debt already incurred, and have a plan to pay it off.”
That’s part of a solid formula for using technical debt wisely: Understand what it is (and how to explain it to others), what causes it, and what benefits you gain from taking it on – the “equity” in the financial-technical metaphor. Then, as Fell says, track your balances and have a plan to pay them off over time.
[ Before you discuss tech debt with your bosses, customers, or partners, learn how to explain technical debt in plain English. ]
In a sense, repaying technical debt is simple: It is just a matter of going back and addressing the tradeoffs or compromises you made in a system to achieve a particular goal or benefit, such as meeting a critical deadline. It’s when you never actually do this that trouble abounds.
4 ways to repay your technical debt
We’ve previously addressed what technical debt is, and why it exists in the first place. As described above, the how of repaying technical debt may be fundamentally simple, but it becomes far more complicated when you can’t solve the where (it exists) or when (to repay it). Let’s look at four strategies for solving this problem.
1. Set "repayment terms" for your technical debt
Financial debt typically comes with a specific payment due date – say, the first of every month for your mortgage payment. Unchecked technical debt, however, will happily saddle a codebase forever if you don’t set those repayment terms yourself.
That starts with knowing where debt exists (see also #2 below) – you won’t necessarily receive a statement or bill every month. Then set a plan for paying down your balances so they remain manageable.
“Do a full tech debt audit and create a timeline to pay off all that debt with a follow-up process to make sure your company doesn’t move forward carrying a high debt ratio,” suggests Mike Duensing, CTO and EVP of engineering at Skuid.
2. Listen to your developers – closely
From an IT leadership perspective, you’ll need to keep in mind that you might be a degree or three removed from the day-to-day maintenance work (or “debt service”) that typically comes with technical debt in a codebase.
This is one way that technical debt can spiral out of control: You simply don’t know where it exists, or to what extent. That makes it kind of impossible to address (or “repay”) later – so make sure you’re asking questions and understand where the debt exists in your organization and its systems.
Moreover, make sure you’re listening – not just to the answers when you proactively ask questions, but on a regular basis. In particular, don’t be too quick to chalk up the complaints of your development teams as disgruntled grumbling. There might be a pattern in the feedback signaling that it’s time to address a particular balance owed.
“If every time they go into an area of code, developers are voicing how they are working around a poor design, this is a warning flag that requires attention,” Duensing says.
[ Learn the do's and don’ts of cloud migration: Get the free eBook, Hybrid Cloud for Dummies. ]
3. Treat technical debt as part of your overall strategy
The audit that Duensing recommends may be easier to achieve if you plan for it from the start, meaning: Bake technical debt (and its repayment) into your overall software development pipeline and strategy.
Fell notes again that tech debt isn’t inherently bad. In fact, it can make great sense in early-stage products or with the minimum viable product (MVP) approach to development. In general, it’s a welcome tool in environments under pressure to ship code faster and more frequently (which is to say, almost all of them.)
“Repayment requires an understanding of what tech debt is and where it exists in the product, an estimate of the ongoing maintenance costs, engaging the business on the timing of other investment decisions, and including tech debt payoff on a software product roadmap,” Fell says.
Indeed, it should be treated not as a dirty word but as an explicit part of that roadmap.
“I think that tech debt should be a part of well-maintained technical strategy,” says Yoseph Radding, a software engineer and co-founder of Shuttl.io. “Instead of planning big features, engineers should work to plan smaller milestones that get the product to market faster, but also plan on how to pay down the technical debt that they create.”
4. Find the repayment practices that work best for you
Some teams may find that easier said than done, so let’s look at some practical tips for actually addressing technical debt over time. A general theme here is that you’ll need to set priorities based on the criteria that matter most to you and your organization. Here are some options:
Track the maintenance costs (or “interest”) and prioritize accordingly
Conventional financial wisdom says to pay down higher-interest debts first; for example, like a credit card with a high interest rate. You can apply a similar principle to tech debt by tracking and analyzing what it costs you over time.
“One strategy that has worked for me is to have a separate task board that tracks how much time, in human hours, [is] spent [maintaining] a particular piece of tech debt,” Radding says. “If the [human]-hours result is too high, then that is a piece that we have to tackle immediately. Having the time in hours shows the business how much money is sunk into the problem and [enables you] to prioritize the fix appropriately.”
Consider other prioritization approaches
Scott Ambler, VP and chief scientist of disciplined agile at Project Management Institute, notes there are two common tactics for managing technical debt.
One is to tackle the biggest problems first. “Biggest” could be measured in something like human hours, as in Radding’s example above. Ambler also points to error rates as another metric. Regardless, the idea is to address the largest or most urgent debts first, though Ambler notes there’s a cost-benefit consideration here.
“You can look at the most pressing debt – e.g., identify where there are the highest error rates or what will have the biggest impact on the business – and address it first,” Ambler says. “This can sometimes take longer and is often a more involved process.”
There’s a flip side to that strategy: Knock out the smaller issues first as a means of achieving faster results.
“This approach offers more immediate results and can quickly show business leaders the value of paying off technical debt – especially if you need their buy-in to support the larger repayment efforts,” Ambler says.
Allocate specific amounts of development time for repayment
“We’ll deal with that later” is not a plan. Bank scheduled time and resources to manage technical debt. Agile teams (or any team that applies agile or DevOps principles to their work, really) can create user stories for tech debt management, for example. Regardless, the general idea is to take whatever methodologies or practices your team works with and apply them to technical debt appropriately.
“A best practice is to allocate stories for debt remediation in each sprint,” Duensing notes. “This ensures you will continue to make incremental progress.”
Incremental progress – rather than zero debt – is usually the right goal. “Zero progress,” on the other hand, is not advisable…
“With mismanagement, tech debt can cause your development team to fall apart,” Radding says. “Tech debt management is an essential part of engineering.”
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
