[gilbetron]

I hate the term "tech debt", although I appreciate that it is a way to communicate with non-technical decision makers. It isn't debt, we don't have to pay it off.

I consider it a coefficient of development friction that must be managed to be an appropriate level for your strategic (business and technical and other) goals.

You want it as low as possible, but bringing it that low costs development effort that could be used on other efforts. Too high and simple changes take days and steals from productive work.

Greenfield development has a near-zero coefficient, which is why it is so fun :)

[dougpa]

It does have to be paid off. A business's technical division can, and inevitably will, become insolvent due to the accumulation of that debt. I take it you've never worked at a company which, after a fast & high-complexity period of startup-development, has had its development grind to a near-halt? Where it takes weeks to make a one line change? This is the analogous equivalent of insolvency for tech debt.

[gilbetron]

I disagree, it doesn't have to be "paid off", no one is waiting for the "money". Rather, design and code decisions may need to be addressed in the future to alleviate development friction.

I have worked in places as you describe, and tech debt is still a bad analogy. It isn't debt, but rather friction, which is a much better analogy.

[galdosdi]

Well, real debts don't have to be paid off either. Debt IMHO is a fantastic metaphor if we look at it in more detail, from both the financial and software side...

SUMMARY: tech debt is just like financial debt, but with a clock whose speed varies with the rate of change of use cases and dependencies. Also, more subjective because instead of borrowing fungible money, you borrow extremely illiquid (and thus hard to objectively appraise) assets (like the notebook your great great great grandmother wrote her recipes in, or that Mario 64 cartridge we've been hearing about lately, or the mona lisa, or the last gas station in manhattan, or the vacant corner lot that's next to your house but can't be built so is of little use to anyone else, or the goodwill that the Disney name has -- all very real assets that could be conceivably borrowed through some kind of future contract, and many of them appear on real corporate ledgers and are reported on real SEC form 10Ks).

Financial debt doesn't "HAVE" to be paid off either, so that's no objection. A special purpose LLC subsidiary or something can go bankrupt. A security can drop to zero value and be written off. Just like a codebase can be abandoned, possibly in favor of a rewrite, possibly just entirely.

What's confusing you is that in finance, the clock marches on and interest accrues at a constant rate. But with tech debt, time only passes as fast as the software gets used, generating new use cases and usage experience that demand features and bugfixes. Software that doesn't get used doesn't pay interest because the clock is stopped. The more it gets used the faster the clock spins and the more interest collects. If it reaches an equilibrium where use cases and dependencies aren't really evolving anymore, like some sort of small core system library component like a heavily optimized sorting algorithm, time slows down again. Although the day a change comes -- eg a new weird CPU architecture that makes the old algorithm suboptimal -- time will pass again.

You do have to pay the tech debt, if the clock keeps moving. But dead men tell no tales and unused code does not "age"

The other confusing thing is financial debt is one dimensional. $1000 is $1000 is $1000. But there is no unit of exchange for tech debt. It's like bartering, like I have a monkey and a jar of pickles and who knows what each one is worth to anyone. A codebase well adapted to certain types of changes might be poorly adapted to a very different kind of change. Like maybe one codebase has hard to change business logic but easy to re-optimize the performance on a new architecture, while another one has mediocre performance on any but the chosen architecture but has very flexible business rules. So pricing is not well defined. My jar of pickles might be worth 2 cows to me, or 40 personyears of legal services to you. Who's to say? Without a way to trade, we cannot value tech debt except subjectively relative to our own use case.

[gilbetron]

That is an incredibly overwrought explanation that even more of an argument against the analogy.

Much like a joke, if you have to go to great lengths to explain an analogy, it is a bad analogy.

Tech debt is just a bad analogy, with a bit of use because friction is less understandable (but more accurate) to many financial and business people.