Technical debt is not debt; it’s not even technical

A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.

>> Cunningham disliked the notion that technical debt signified “doing a poor job now and a better one later.” This was never his intention.

You can split hairs of weather code was poorly written vs written from an underdeveloped understanding of the problem, but the effect is the same. People have to deal with suboptimal design decisions repeatedly until they are corrected. To extend the debt/interest metaphore, these poor decisions also undergo compounding if not paid back.

getting it to walmart is where the chefs get bored and turn one amazing night into years of backlog refinement

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.

I've always assumed engineers (myself included) write code to the best of their abilities to solve a given problem at the time. But we all know that, over time, features and such get added to the code base and it is stretched beyond what it was originally meant to do.

That the code base would should be refactored to better accommodate these new features that have been glommed on is the tech debt. There was nothing poor about the original implementation and the additional features were added with the understanding that the code could not be rewritten from scratch.

I may be splitting hairs here but I want to make the distinction that at no point was an engineer making poor choices.

I want to point this out not to sound defensive, but rather to make it clear that when I use the term "tech debt" I am not saying it in a castigating or "accusational" way. There is no shame in tech debt.

(BTW, other engineers I've worked with, will add a "BOGUS" comment next to any line of code they are in fact embarrassed by with some explanation like "using very small number here, render crashes if border is zero thickness.". Do a search for "BOGUS" in the sources to discover you BOGUS debt.)