My post What Technical Debt is and Isn’t got a lot of feedback, and today we’re going to talk about why my definition for Technical Debt is so narrow, and why yours should be too.

The feedback encompassed a few categories, “Future change”, and “Bad Decisions”. First, on future Change:

Why having to change in the future is Technical Debt:

I’ve linked to the tweet above and from there you can see the whole thread; but in sum: New technology causes you have to rearchitect and rethink your system in order ot catch up with a competitor.

That’s not technical debt. That’s the normal course of business.

As I’ve said before, Technical Debt is a poor metaphor; but the idea is the same: an action you take that causes you to go faster now at the expense of later.

Technical debt is not a lack of omniscience. By making technical debt about something that happened that you couldn’t have foreseen, you’re encountering (at least) two problems:

1. The ability to shrug off actual business competition as technical debt. “Oh, that’s technical debt.” as if you and your team made a purposeful decision. You didn’t, the world changed! Think about it this way, when Cars came along, the people that sold horses didn’t do anything wrong that caused them to go out of business, The world changed! In this case, there is no elusive ‘debt’ to blame for this; it’s just a function of change. How you and your team respond to it is important; but it’s critically important not to lump it in with shortcuts you’ve taken that caused this to occur.
2. You end up lumping in things you can’t control (the world changing) with things you can control (how you build your tech stack). By labeling things outside of your control as Techdebt, you’re just putting a target on your back, as if to say “Well if we hadn’t taken shortcut x this wouldn’t have happened”, when that’s not the case. No, companies probably shouldn’t operate according to blame, but by mischaracterizing what technical debt is, you’re giving ammunition for someone to blame you, wash their hands of it, and call it a day.

The second category of feedback is that “Technical Debt” == “Bad choice”:

And once again, I’ll go to the well. Technical Debt is not the same thing as making bad choices. “Bad choice” is an outcome. It’s not something you can know at the time (presumably if you did know you wouldn’t have made it). Making bad choices is making bad choices. That’s trainable and that’s something that can be managed by experience. The solution forpreventing bad technical choices is different than it is for preventing Technical Debt.

The cause of bad choices can be: politics, bad hiring practices, not understanding the technology in use, and internal culture.

Those have their own solutions, like focusing not on individual ‘getting ahead’ but on providing team success towards a specific outcome, improving hiring practices through training, having a mandate that technology choices are vetted or known before they’re used, and taking steps to identify how the internal culture results in bad decisions and working to improve that.

With Technical debt, the team made a decision at a certain point in time to purposefully take shortcut x to produce outcome y faster. It was a conscious decision, made with intent.

This is important to note because on the one hand, the company or team is owning the responsibility on the choice (technical debt), and on the other hand, the company itself is the problem and may not own the responsibility for causing the problem. As the saying goes, we have seen the enemy, and he is us.

Or, think of it this way: “Yes, we purposefully chose to do X and that got us to our short term goal faster but now we need to re-architect X to meet goal y”.

“We didn’t know what we were doing so we chose X because it seemed popular”.

How do each of those conversations speak to the competency of the team? Does the latter speak to this amorphous ‘technical debt’ that exists that we seemingly can’t do anything about? No.

Bottom Line

For your company and for your technology organization, it’s important to separate out the decisions made because you didn’t know better from the decisions where you did know better, but did it anyway. It’s not just for accountability, it’s to improve your organization and your team. By throwing all decisions that you don’t like into a pile called “Technical Debt”, you lose the ability to separate out the instances where you can do better, vs instances where you couldn’t have done anything differently, or more importantly, anyone else in your shoes wouldn’t have done anything differently. That’s important, especially if you want to keep wearing your shoes at your company.