Debts, Tech and Otherwise

Feels like we're stretching the metaphor when we apply it to things that won't necessarily compound in complexity or time required to fix it. This is often the case with technical stuff because things can depend on one another, but if you drop a bad process step, the time saved is probably linear since rarely do other teams need to change their process because you changed yours.

Debt is scary as a metaphor because the interest compounds and the bank can repo things, but if you just owe a guy $10, he's not gonna come after you years later with a $300,000 bill. Non-compounding bad decisions are "you owe a guy $X" while the compounding ones are "debt".

Maybe we should use "fees" and "debts" to differentiate these.

In an attempt to get a more general version of a debt metaphor, let's look at ingredients: - there is a time interval - we have a utility function, or at least desire one or want to pretend we have one - there is a decision - there is uncertainty

From here there are many paths...

"Deliberate vs inadvertent" describes whether we know about the effect the decision has on the utility function.

"Reckless vs prudent" describes whether we are rational and realize that decisions have consequences.

It is also possible that we don't actually have a utility function. Or different people involved in the decision have different utility functions or don't feel the same responsibility towards the outcome (not unheard of when it comes to maintenance/design/architecture vs feature).

What makes the debt metaphor very attractive is that it evokes an image of being in control. We may not have spelled out the utility function but everyone agrees it is bad now so we can pretend it was a rational choice we had. The alternative that we did not take any decision when we could have or were too distracted to see the consequences is much harder to accept. So now that we have debt, let's talk about whether we choose to pay it back or now.

Rather than working hard to create this faux image of control, I wonder how often teams may be better off having an honest discussion about what the utility function is or should be, which decisions will make the group move in the right direction and how the team can keep oneself accountable that the effects that one had in mind actually took place.

The survivor bias section at the end is summed up by a favorite response to premature scaling work at a startup: “We would be very fortunate to have that problem.”

I really liked Yvonne's reframing of tech debt as house work: https://mastodon.social/@yvonnezlam/112474946704366947

no metaphor is perfect, but I think figuring out who is impacted and how by decisions to rush or skip things is important.

reforge has a great post where they classify the various types of debt in digital product development: maintenance debt, developer efficiency debt, stability debt, security debt, technical product debt, decision debt. https://www.reforge.com/blog/managing-tech-debt

[dead]

I can call an ink pen "a sword". I can even justify this by saying some nonsense like "pens are used to wage war". But if I rush headlong at a Samurai with nothing but a Bic Rollerball, I should not expect to come out of the encounter with all my limbs, much less the expectation of injuring the Samurai. Just calling it "a sword" doesn't mean it has anything to do with an actual sword.

"Tech debt" isn't debt. It has nothing to do whatsoever with the concept of debt. What people mean when they say "Tech debt" is really "I'm putting off work I know I should be doing now, until later, and I'm doing something else instead that I know I'lll need to undo" That's not debt. That's procrastination. That's delaying the inevitable. It ain't debt.

You don't pay off a car loan with procrastination. You don't decide to put off painting your house and then call that a loan.

"Tech debt" has nothing to do with interest, with a lienholder, a creditor, a payment plan, etc. There is nobody to call in the loan. There is no incremental payment. There is no credit. There is nothing whatsoever to do with the entire concept of debt, much less any of the actual practical real-world implications, actions, or actors, behind debt.

Please let's stop perpetuating this cargo cult myth. There is no such thing as "tech debt". There is only compromises and procrastination, and justifying regrettable decisions by pretending there's a good rationale for them. There isn't.

Tech debt is such a flawed concept. There is no world where requirements 10 years later are the same as the MVP, or even foreseeable. You can never pay it off. Software is always changing.

Even if it were debt, debt is a tool to get you what you need today. And then you likely roll it into something down the line. Maybe you pay it off (and even then the asset still requires maintenance) Like a starter home, then upgrading to a larger home to start a family, etc, etc. Requirements and resources are in constant flux.