Tech Debt Just Means Messy

A few days ago I read an essay about tech debt metaphor maximalism. I've written about this before from the opposite position so it was interesting to see the counter argument being made that the problem with the tech debt metaphor is that it's not being taken far enough.

First off, the post is an excellent overview of financial concepts surrounding debt. It covers many more concepts than those I present in my own piece including high versus low interest debt, various debt ratios, and refinancing. I think it's a light hearted primer on debt and I quite enjoyed its work at making such concepts approachable.

There's also many points I completely agree with the author. For example,

Tech debt, in its simplest form, is the time you didn't spend making tasks more efficient. When you think of it that way, it's obvious that zero tech debt is a silly choice.

Completely. I even addressed this in my own piece. I note that the amount of cleanliness should be proportional to the type of safety you require in the work you're doing. From a pure mess standpoint, existence itself is a form of mess. It's entropy in an otherwise pristine nothingness. Said another way, the best code is no code at all because there's nothing to maintain.

That said, there were also places we came to completely different conclusions because of the metaphor we choose. For example,

What's weirder is that as the absolute value of product equity increases, you can take on a larger and larger absolute value of tech debt.

That feels unexpected. If we're doing so well, why would we want to take on more tech debt? But think of it this way: if your product (thus company) are really growing that fast, you will have more people to pay down the tech debt next year than you do now.

The author goes on to use the concept of leverage to describe why this often fails. They say that managed properly, it makes sense for the mess to get bigger if you're growing because next year you can hire more people to go clean it up. When this doesn't work it's because you over leveraged. You made more mess than you could hire to fix.

Why do I disagree? If I make a mess of my room I can clean it up. I can even make sweeping changes to do so. I could move the bed, replace the dresser, or throw away the cloths on the floor that I'm not going to wear again anyway. When you hire a janitor they can sweep and scrub but they're not going to go and throw out your stuff as a first choice to deal with it. I'll wash and fold your floor cloths at considerable time and cost only for you to later explain that they could have just been tossed. You can only refactor your space when you know why everything was put there in the first place.

Hiring code janitors to clean it up is often going to take more time and money than just cleaning as you go. Who wants to go work somewhere they'll be writing unit tests and documentation for a thing the person who quit before them did? I can say from experience you'll try and those people will quit in a few months when they figure out what you're trying to pull.

That's especially true since, as I pointed out in my essay, we don't have a tech debt unit. There's no numbers involved and this essay still hasn't addressed that. It's all just rhetoric. The author even shows some of the math of debt but doesn't once bring up a single code metric that follows the same model as debt. Not even lines of code.

I still wonder though, why are we trying to use a complicated concept like debt when something much simpler exists? Throughout the piece I've shown a couple example pictures of the classic over patched networking rack. What do we get trying to call something like this tech debt? I think we're just trying to hide behind jargon to make ourselves feel smart. It's just a mess. Even children get what a mess is. I don't think it improves our communication when we try to explain how it's kind of like capital leverage (and what that even is) when we choose to ignore a mess for now and schedule time to clean it up later.