Another (Better?) Take on Technical Debt
In a previous article entitled “What Is Technical Debt?“, we talked about nuts and bolts of technical debt. I’ve since come to the conclusion that, although what I presented is the classic definition of technical debt, I believe the label is inaccurate and causes more harm than good in development organizations.
Here’s why:
By assigning previous decisions, typically made in haste, and typically deemed necessary by the business, the label of “debt”, it becomes a pejorative and a topic that no one, especially company leaders, ever want to hear about. Furthermore, the more distance that comes between those previous decisions and today, the greater the tendency for selective recall and blame shifting.
As a result, whenever developers ask for time to “pay down technical debt”, the business leaders either ( a ) roll their eyes, ( b ) dismiss the need out of hand, ( c ) continually make the case that current features and needs are more important than addressing previous decisions or ( d ) all of the above. The thought process that’s happening goes something like this:
- I thought I hired you to make all of the right technical decisions?
- Why are you now asking me to pay you again to do this work over?
- I don’t remember asking you to take that shortcut. You should’ve told me it would cost us back then, not now. We’ve got other stuff to do now.
Whether or not any of this is accurate doesn’t really matter. It’s not how things are, it’s how people think things are.
I read this article not long ago that labeled technical debt as an addiction. The article is worth the read, and the developer in me loves the argument. But even addiction is a negative term and creates a natural point of contention between the development organization and the rest of the business.
My new (and potentially more enlightened) view on this topic is that we should think of addressing previous decisions with new work no differently than working on a new feature for the application. It is, at the root, simply work that must be done in order to move the product forward. By re-orienting this way, we remove the visceral reaction that accompanies this discussion in EVERY SINGLE development organization.
We should stop using the term “technical debt” altogether. I don’t have a great new word, but I’m not sure one is necessary. Sometimes removing a word from the lexicon is as important as trying to make up something new.