On software development teams, “tech debt” tends to be a bucket where old, rushed, or bad code goes to rot. Without conscious criteria for prioritizing a given tech debt ticket, it’s hard to get a team to agree on the value and urgency of fixing things.

The solution? Treat tech debt just like financial debt – use it to accomplish goals for your organization, and keep track of every bit, so it doesn’t get out of hand.

Just like financial debt, tech debt can be beneficial for leverage. But generally, the longer it is put off, the more costly it is to fix. Most technical teams don’t keep track of tech debt enough to even know what is holding them back, and as the team turns over, it loses the information that particular team members keep in their heads.

I’ve known developers who would be happy to address tech debt all day, every day. I’ve also known developers who would be happy to create tech debt at every turn. But these differences can be mended by quantifying both sides of the tech debt equation.

The average organization wastes 23% or 42% of all development time due to tech debt. To address this, more developers are needed for the same delivery rate, but hiring more developers increases coordination costs, which in turn makes the development less efficient, particular in codebases rife with technical debt. It’s a miserable cycle for the organization and a big weight on the developers.

When tech debt is quantified and systematized, it becomes manageable and predictable. Below, we explore how to quantify the costs and make a measured, reasonable decision for each case.

Types of Tech Debt

It’s helpful for the team to share a vocabulary around tech debt classifications:

• Deliberate – Quantified and consciously incurred by the need for speed. This is a healthy part of the development process in an organization with scarce resources, as long as it is taken into account.

• Accidental/Outdated design – Discovered and needing to be quantified & addressed. This entropy is inevitable and needs to be regularly reassessed.

• Bit Rot – Outdated packages, changes in coding style/best practices, naming, etc. Developers are encouraged to consistently clean this up as they go.

• Dark – Whispers of foundational issues. Always bring these to light.

Best-practice processes

Keeping track of tech debt doesn’t require sophistication, but it does requires the team to follow a few rules:

1. Set borrowing thresholds: When over-leveraged, the team must pay off some debt to avoid becoming insolvent. If you are insolvent and the interest is unmanageable, you may have to push back against any work that doesn’t contribute towards paying off the debt.

2. Create a Tech Debt Council that meets every two weeks and discusses, quantifies, and prioritizes tech debt backlog items and their respective architectural decision records (ADRs). Enable your team members to add concerning tech debt to the council’s agenda at will. Consider creating a Slack channel for tech debt discussions. If tech debt tickets are missing required details (see next section), split them up among council members or send them back to the creators of the ticket to complete properly.

3. Write a Loan Disclosure Statement (LDS) whenever deliberate tech debt is incurred. An LDS is a formal approval document that includes all information relevant to the ‘loan’. Accumulate these in one list so everyone can contribute and keep up with what’s there, and make sure you update these as they get paid off.

   • Sample LDS template:
     ———
     Ticket requiring loan:
     Ticket(s) to pay back debt:
     Added by:
     Date added:
     Executive sponsors (who signed off that this is debt worth taking on?):
     High-level objective:
     Anticipated benefits of incurring debt:
     Amount/magnitude loaned:
     Upfront costs & interest:
     Payment plan/schedule:
     Other helpful info:

4. Create a ticket/epic whenever your team encounters or incurs debt. Add the ticket to your Tech Debt Council agenda to be assessed and prioritized. If the debt is very substantial, consider first creating an ADR to propose an approach for addressing it. Make sure you note the originating source of the debt so you can look back later and determine what processes or structures are the biggest culprits for creating avoidable debt. Each tech debt ticket needs to have the following sections filled out in its description:

• • Cost of the debt (more info below)
    
  • Cost of paying it down (more info below)
  • Payment plan (how/when to address the debt)

Make it quantifiable

Note: If you can’t quantify the costs of a piece of tech debt, then it may be just a developer preference (and not tech debt). Bring these up informally with the team – if it is also a strong team preference (>2/3 majority) and very low cost to fix, it can be addressed in a low-priority ticket, perhaps when a sprint’s goals are completed early.

Costs of the debt

For each tech debt LDS and ticket, sum the below parameters to reach a total cost of the tech debt in question.

• Opportunity costs:
  • What are we not able to do because this tech debt exists?
• Headcount:
  • More personnel needed simply to maintain existing systems
  • Additional developer time to bring about new capabilities
• Security risk:
  • Measure by multiplying the likelihood that this debt causes an issue by the cost of the issue
• Overhead:
  • Slower implementation & accommodation of partner requirements
  • Incurred costs from security breaches
  • More bugs arising from changes to the code base
  • Higher risk from unpredictability in planned work
• Sales:
  • Lost partnerships due to implementation limitations
  • Lost reputation due to bugs and incomplete solutions
  • Lost users due to outages & sub-optimal experiences
• Market Intelligence:
  • Inability to quickly adapt to opportunities or changes in the market
• Productivity:
  • More communication required at every level
  • Lower staff productivity
  • Loss of developers who are tired of ‘unnecessary’ work
  • More difficulty in hiring good developers
• Interest: Each ‘loan’ has an ‘interest rate’. This may change over time due to changes in circumstances, but every instance of tech debt can be quantified (at least to some degree) to have a rate of cost over time.
  • How much less (or more) would it cost to fix this now vs later?

Costs of paying the debt down

It’s important to also quantify the costs of fixing the tech debt to see whether/when it is worth addressing. Sum these parameters:

• Opportunity cost: What could we do instead of addressing this debt?
• Direct costs of implementing a fix, in time and money
• Liability: (likelihood * cost) of problems being caused by the fix (security, bugs, downtime)
• Pre-payment discounts: if it would be easier to fix now than later (i.e. interest rate will increase)
• Pre-payment penalties: if it would be easier to fix later than now (i.e. code or fix is short-lived)

Final Consideration

Keeping the net costs and benefits of addressing tech debt in mind, think through this question:

If we had completely cleared up all of our known technical debt in one concentrated effort one year ago, how might this year have played out differently?
Would it have been better or worse for the team and the company?