Yet another way to look at technical debt to help with prioritization efforts

There have been many authors proposing different approaches to categorize Technical Debt.
You have Martin Fowler with his TechnicalDebtQuadrant.
Then you have Uncle Bob making a strong distinction between Technical Debt and "a mess", which I happen to disagree with, a mess is also debt.
Then if you read Uncle Bob's article, I like the comment by Mark H where he suggests perfectly good code can "bankrupt" and become debt. I definitively love that concept.


At the end of the day, let's go back to the root of the word debt.
Using the same theme of dissecting a word definition I used on other articles, let's start by using a definition of the word debt straight from Google:

debt

something, typically money, that is owed or due.

So, in short, a debt is something we owe. Legacy code, messy, can be become a debt? O yeah... it can. Is it always "debt"? Absolutely not!

Go back again to Mark H comment on Uncle Bob's post. The key thing to take into account is when legacy code becomes bankrupt. What's the event that triggers its bankruptcy?

So, putting that digression aside, let's risk a definition for Technical Debt:

Technical Debt appears when we ought to do something about a piece of code in order to keep it viable.

Let's look a the three pieces I underlined:

1. Technical Debt appears: The point of this is that not always we do "create" tech debt from the start, nor in a deliberate or inadvertently way (in contrast to Martin's quadrant). Perfectly fine code, as written some time ago, can become a debt after passing thorough a "legacy" stage. When this happens? when we...
2. ought to do something (about the code): If we have code that is perfectly fine as-is. We are good, there's no debt. If we have a piece of code that it's a mess, and it was born as a mess, we got ourselves into credit card debt, unsecured debt (there's not even an asset to back it up). If debt was incurred in a deliberate fashion to accelerate a deliverable, maybe we are talking of a home mortgage or a line of credit. Or, for existing code that became a liability at some point, maybe we are talking a depreciating asset that it's costing us more to maintain that the intrinsic value it provides. Either way, as soon as we have a piece of code that we are forced to plan to take action upon it in order to...
3. keep it viable: we are talking about technical debt. It may happen we have pieces of code that are not "ideal", perfect, algorithms that are not necessarily the best performing for a problem but they are definitively "good enough" in our market or as required by our clients. Are those debt? I would argue they are not debt. A piece of code becomes debt when its viability is in question. A perfectly nicely written piece of code can become debt if suddenly a change in its running platform makes it obsolete or unsupported. The code is great, nicely written, but its viability is in question.

Now that we cleared what is debt (to a degree) from what is NOT debt, let me propose a simple two-way to look at technical debt that should help prioritize paying down.

As with any debt, I like to think it in terms of two types:

1. Neutral
2. Debilitating

Neutral Debt

Why the word "Neutral"? Well, I wanted to use a word that doesn't denote good or bad. Something in the middle. This is in purpose, because personally I believe having no debt will be the ideal we should strive for, yet sometimes we will have to incur on it but definitively I don't want to portray that as a net positive. Therefore the choice of "Neutral" as a word to define it.

What is Neutral Debt?

Neutral Technical Debt is debt that doesn't endanger the product operation nor poses increasing monetary costs to keep the code viable on the short to mid-term.

In another words, we know we have to do something about it, we know it will break down at some point, but at this point in time and for the mid-term (pick your length of time that best fits you) the code will work and it won't be a resource drain to maintain. The code is still an asset, it's doing it's job, yet we know we will have to do something about it "at some point".

Debilitating Debt

Easy. Pretty much negate Neutral Debt and you got Debilitating Debt.
You got a piece of code you find yourself investing time again and again to keep it working. You fix a place, and break five places inadvertently. Each new feature you add the code smells multiple like well fed rabbits. Your backlog is filled with "refactorings" in order to add new features. And all of this is happening right now, and getting worst everyday to the point you can't even think about the long term.

Well, I could keep going on the narrative above. You get the point. Look at the word I used: "Debilitating". With this type of debt, you become weaker every day, you can do less of what really matters because you find yourself on this never ending cycle of fire fighting broken and unwieldy code.

Prioritization

So, when need to do your next technical debt prioritization meeting, try separating it first into Neutral vs. Debilitating debt and only focus on discussing Debilitating Technical Debt to further decide what to do.
Upon the right time there will be pieces of Neutral Technical Debt that get "demoted" (or if you prefer "promoted") to Debilitating Technical Debt. Maybe that's how you start the meeting, quickly go thorough existing Neutral Technical Debt and assess if any entry should be changed to Debilitating.

If you want to get fancy, you can rank them from #1 to #5, with priority #1 being the worst ones, those that get your company hooked in those strong painkillers (being your team the painkillers).

Hope this helps your tackle your technical debt problem.