Aaron Stannard on Technical Debt and Optionality

I’ve written about technical debt before, (and will probably write about it a million times before all the writing is done), but the reason we’re chatting today, or rather, the reason you’re staring at these words on your computer monitor (how quaint), is that Aaron Stannard has written about technical debt too and he adds a dimension I hadn’t considered previously: optionality (if you’re into investing, this is similar to stock options or options trading).

I think this is a thoughtful and useful take; and it’s worth your time.

You can also find Aaron Stannard on twitter.

Why “Technical Debt” should be narrowly focused

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 for preventing 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.

What Technical Debt is and isn’t

​Technical debt. In tech, I’m not sure there are two words that are more confusing than technical debt. It means something different to everyone.

It’s important to understand what technical debt is and isn’t, because some day, some day soon, you’re going to encounter misalignment on what it means in your own teams, and there, as they say, be dragons.

Tech Debt is, at its heart, the natural consequence of shortcuts taken ​purposefully​.

Tech debt is not:

  • bugs
  • design flaws
  • design choice tradeoffs
  • unknown requirements being realized
  • a way to go further (it’ll let you go faster, but not further)
  • revolving debt

All of the above exist, of course, but they aren’t ​technical debt​.  The difference is that technical debt is a ​purposeful design choice designed to get to <goal> faster by taking a shortcut​. ​There are lots of ways of going faster without taking shortcuts, but teams rely on technical debt because it’s easy to accrue (this may be the only sense in which it is like credit card debt). ​

Why does this matter?

For all the pedantry developers have, we sometimes are loose with our words. Technical debt is one such phrase that’s been used loosely to mean all of the above, and it’s caused quite a bit of consternation across the industry because of that.   CEOs hear ‘debt’ and think something they can just pay the interest on forever on without paying down the principal; and technical debt doesn’t work that way (that’s primarily why ‘debt’ is a bad metaphor).  Technical Debt is not credit card debt.  At some point in your company’s life, you will pay off the debt.  That time may be never, or it may be tomorrow.  But the most insidious thing about technical debt is once you realize you have to pay it off, it’s often politically easier to rewrite the application instead (even though that’s generally far more expensive than fixing the debt).  

How does your team use the term “Technical Debt”? Reply and let me know.