Technical debt is just an excuse

We need to stop using the term “technical debt” as an excuse.

Ward Cunningham coined the term and gave it a precise meaning. For Cunningham, technical debt was a conscious decision. The development team, while realizing that there is a better, more “correct” way of doing the job, chooses a more expedient way that has costs down the line. Those costs, of course, are more bugs and more difficulty in maintaining the “wrong” way of doing things. 

This decision is usually made to speed things up, with the understanding that the development team will go back and “fix” things later—hence the notion of “owing a debt.” One could argue that it isn’t really technical debt unless you have a Jira ticket in the backlog to fix the deliberately bad chunk of code.

But let’s be honest here. We’ve twisted the term so far, it’s become meaningless. Not every pile of crappy code in your repository is technical debt. We call it that, but how much of it was a deliberate decision? How much of it has a plan in your backlog to fix it? Not much, right?

Technical undebt

The term “technical debt” has lost its meaning. Now, we use the term to mean “all of the awful code we have in our system that we know we’ll never go back and fix because it is both too costly and too risky to change.” 

All of this crappy code has three origins:

1. Technical debt: This is the code that you know is sub-par, but that you decided to write for good reasons, and that you have a plan for correcting. Let’s face it—hardly any code out there fits this description. How many development teams actually have a plan for paying back technical debt? Not a lot.
2. Accidental complexity: Fred Brooks coined this term, which perfectly describes code that isn’t right and that results not from negligence or bad coding skills, but because no one understood the system and made bad decisions. Maybe the team chose a framework that was way too heavy for the task at hand. Maybe the team created unnecessary abstractions or added a feature in a way that doesn’t match the system. Sadly, this is the kind of thing that doesn’t appear until well after the fact.
3. Just bad code: Most of what gets called technical debt is just rushed, slapped-together, or “emergency” code that was never reviewed, or was glossed over because it “worked” and the customer was screaming. band-aids for customer fire drills, critical bug fixes that were checked in over the weekend, or artifacts of developers working without enough time, clarity, or support.

A pretty label

The problem with calling it all technical debt is that it puts a pretty label on avoidable problems. We give ourselves an excuse to do the wrong thing because we can give it a fancy name that implies we’ll “pay it back” later, when everyone knows that we never will. When the team is allowed to use the term to justify not doing things the right way, you’ve got a culture in decline. 

In addition, labeling all the bad stuff technical debt can lead to justifying bad decisions and practices. It can hide problems like under-investment in engineering and toxic, constant deadline pressure. 

So let’s stop doing it. Let’s all agree that we can’t call it technical debt unless we actually have a backlog item to fix it. Real technical debt should have a work ticket, a correction plan, and a deadline. Anything else should be recognized for what it is: crappy code. Let’s build a culture where we have real technical debt, and where we call everything else by the right name. Let’s reserve “technical debt” for what it actually is: a conscious tradeoff with a repayment plan.

Everything else? It’s not technical debt. It’s plain old code rot.