I recognize that there are n "technical debt" articles out there, so here's n+1.

What is Technical Debt? 🙄

Technical debt is a metaphor coined by Ward Cunningham.

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. - Ward Cunningham

Since then, its meaning has changed so much that we now treat it like a quantifiable thing. Now, software engineers tend to say things like "This ticket is technical debt" or "We don't get enough time to spend on technical debt". That ultimately leads to the question: What is Technical Debt? The best answers are always vague and highly disputed.

There's a very good reason for this ambiguity. Technical debt isn't a thing. It's a situation, and you are in it.

How do I know I'm in Technical Debt? 🤔

If you are in technical debt, then you will find yourself doing more work than necessary to complete an objective. This usually manifests itself as a workaround.

Organizations that don’t pay down technical debt can find themselves so burdened with daily workarounds for problems left unfixed that they can no longer complete any new work. - DevOps Handbook

What can I do about it?

First, you need to identify the workarounds. For most people working in a codebase for a significant amount of time, this is pretty easy to do.

Once you have identified the workarounds, you have three options.

• Do nothing.

• Resolve the workarounds as a part of upcoming feature work.

• Devote a percentage of your team's time to resolving workarounds.

Do Nothing

Depending on how long you expect the codebase to live and depending on how long those workarounds take away from your upcoming work, this can be a perfectly reasonable option. Most of the time, this option manifests itself as the ticket that has been sitting in the backlog for more than three months.

Resolve the workarounds as a part of upcoming feature work

This seems to be a popular option today. The trick with this idea is that you need to understand how much time the workaround costs, how often you need to employ the workaround, and when your objective is due. If you can achieve a net positive change in the amount of time to achieve your objective by fixing the workaround, then have at it.

Devote a percentage of your team's time to resolving workarounds

As far as I'm concerned, this is the standard method. Even so, it always seems to fail for a few reasons:

• The percentage is only recognized within the team. For this to work, the entire organization needs to adhere to this. If your team devotes 20% of their time to paying down technical debt, then the organization's view of your team's 100% capacity must be 80% of your team's capacity. If the organization sees your team's capacity as 80%, then this method will fail.

• The tickets to resolve workarounds are deprioritized. For this to work, you need to prioritize the tickets to resolve workarounds. If your team devotes 20% of their time to paying down technical debt, then your backlog should always look like this: feature, feature, feature, feature, resolve workaround, feature, feature, feature, feature, resolve workaround, etc.

Takeaway

Technical debt can be defined by the time lost employing workarounds to achieve your goals. To pay down technical debt, your team needs buy-in from the top of your organization and the diligence to prioritize it. Pick a system, stick with it, and you will see results.