The Debt metaphor sucks, Part 2

Not too long ago I wrote on my dissatisfaction with the 'technical debt' metaphor, to much applause and adoration.

And also some browbeating. It turns out people get pretty worked up about metaphor.

Where I missed

The raison d'être for the Technical Debt metaphor is to clarify the exchange of "taking a technical shortcut or otherwise amassing future work" for "immediate business value", something that I didn't cover in the previous article.

If you have taken on Technical Debt as part of product development, you've made an intentional decision to cut a corner in order to affect some positive business outcome. This exchange should be very much like going to a bank to take out a loan in order to finance a car. You get an immediate positive outcome (a car) in exchange for a shortcut that you are obligated to repay throughout some future slice of time (the lifetime of the loan).

In other words, if you didn't make an intentional decision and see a positive business outcome, you didn't take on Technical Debt – just like you can't accidentally stumble into a loan, and you wouldn't take out a loan if you weren't going to spend it on something.

So why 'clutter'?

The previous article makes a big deal about how the debt metaphor isn't useful and that a cleaning metaphor is more accessible, given that most people are more familiar with cleaning than banking.

The reality is that the metaphors serve two different purposes. The debt metaphor describes a very specific tradeoff, while the cleaning metaphor describes decision making through the lens of habitability. And in my experience the latter is the more prevalent in modern development. At least for the contexts that I've been in.

I worked on a project recently that was primarily written in JavaScript (both Node.js on the back end and React/redux for the front). Only once was there an existential threat that necessitated taking technical shortcuts to achieve some business goal, but we had a lot of other conversations about "technical debt". These conversations centered around sloppy code, sloppy patterns, or the ever-present need to upgrade libraries, frameworks, build systems, etc.

These were the systems for which the cleaning metaphor was more apt. Keep your libraries up-to-date, ensure your units are loosely coupled, make sure the tests are robust, pick up your socks... The habitability of that particular codebase was a bellwether for the success of the project. Let React slip a few major revisions (estimated time: 3 months) and suddenly your tertiary widgets are unsupported and you're having performance problems.

The specific impetus for the cleaning metaphor was to describe (and condemn) the endless discussions we were having on linting rules. To move over to the metaphor, we were having weekly (sometimes daily) arguments about what color the cleaning supply caddies should be. Yes, having a caddy to carry around your cleaning supplies is helpful, and if they all need to have the same shape and color then let's pick one and go, but revisiting so frequently was having an impact on my ability to actually, you know, clean. And how clean does this room have to be, anyway? We're planning on demolishing this house next week.

Actual example of Technical Debt

We had inherited some "less than habitable" code, and a few Very Loud Customers were reporting performance issues. "We can't load the page!" they would report, loudly, every few hours.

Obviously something had to be done, but the code was in such a state that a maintainable solution would take too long to implement.

We decided to take on technical debt in order to stop the phone calls. We sent a few extra requests to the backend, introduced some undesirable pagination, and added some cheap caching to ensure that the customers would be able to load all their data.

It worked. The phone calls stopped, but we felt super nervous for the next few days until we had paid down the debt.

In this case the application of the term Technical Debt is an apt one. We committed to some work that we knew to be a shortcut (with the intention of undoing it and re-implementing a more long-term solution later), and in exchange our users were more quickly able to load all their data.

And so...

One may argue that language is fluid, and metaphor more so. After all, "literally" is now understood as both "literally" and "figuratively", as in "his head literally exploded after packing his mouth full of fireworks" and "when people stretch the debt metaphor too thin my head literally explodes". So why does it matter if the metaphor is misapplied sometimes?

To these people I say: shut up I understand and respect your opinion. I believe, however, that by being precise with these metaphors we can apply better priority heuristics to our work, and thus will be able to maintain a higher level of customer satisfaction. If I, as a Product Owner, hear developers talk about Technical Debt that needs paid down only to discover that they have spent the past few days refactoring an area customers don't care about, I'm going to trust their opinion less over time, à la "The Boy who Cried Wolf".

So maybe I was a little harsh on the term "Technical Debt". It has its place, as a very specific metaphor that shouldn't be applied too deeply. "Technical Clutter" is more versatile, but applied to a wholly different set of behaviors.

Big thanks to Chris Shinkle for coming at me with torches and pitchforks over the original article. I've never seen a single man carry so many improvised weapons.