Right, and "debt" is a beautiful word here. It accurately describes receiving the value today, but then owing that time back, with interest, in the future.
Some forms of debt are a headache if the business goes south but tech debt can be ignored if the software project goes nowhere. So the “terms” are good.
Rather than complaining about tech debt, one should communicate the advantages of paying it down or the risks of taking on too much. But the metaphor works and simply referring to “debt” will not dissuade people because a bit of debt is fine.
Consumer debt is mostly unsecured, almost perfectly fungible across term structures and refinanceable on a whim within a very competitive market of lenders. It's rare for it to be essential for a consumer to take on debt to continue to live[1] and there are typically safeguards in place to ensure consumers don't take on too much debt burden. The only debt that most consumers will come across that imposes any restrictions, or moves slowly, is a mortgage on a residential property. When we talk of "technical debt" we are talking of something has none of the nice properties of consumer debt. If I had sufficient cash I could pay off all my consumer debt within two minutes with a few taps of my phone screen.
On the other hand, I interpret "technical debt" to be akin to a complex structured financial product. Maybe there are convertability clauses between debt and equity, perhaps there is variability in the rates payable, or optionality that can be triggered by various real world events. This form of debt is not liquid, it is not refinanceable and it can be hard to find someone to take it off your hands for any amount of money! Nonetheless, sometimes it is essential for a business to take on this sort of debt to continue to thrive. That is an apt meaning for "technical debt" in my opinion.
[1] rarity depends on how socialised one's healthcare system is!
A good litmus test here is to ask someone, “what if I told you that technical debt was originally a good thing?”... Like “Yes! Let’s go and get some technical debt, it will be great!” And so, can you understand why it might have started out that way?
People who really get the metaphor, can understand why it was originally a good thing to be desired. Because debt is a useful tool for the same reason, and if you can pursue what “being unable to take on technical debt” looks like, you can understand that it was a reaction to waterfall-style approaches.
But a solid 80-90% of people in tech don't understand how it could possibly be positive... “tech debt” is just a shorthand for the stuff that is causing development to go slower than you would have liked it to go.
Technical debt is by definition created to save time, so there is rarely an understanding of the risk that comes with the debt until the debt must be repaid. This means that the eventual payback can range from inconsequential to disasterous. The point is that the debtor won't know until it comes time to pay the debt back. Technical debt is often incurred in lieu of actual planning, not because a debtor is consciously and rationally weighing current reward against a future risk.
In that case, it is a very apt metaphor because most people naturally see debt as a bad thing. But with some nuanced thinking and deeper investigation you recognise that it can be useful sometimes.
The 'technical' part points out that it's a special kind of debt, one that isn't measured directly in money. What's the debt? The debt is time.
You can't move some technical (which isn't a noun), or some money (which is), from one account to another, to pay down a time debt. You have to pay it off with skilled labor, which takes time in a way that isn't fungible with money: there's a lot of COBOL out there which can be lightly modified, or replaced, but that company can't find the hours of skilled labor to do more with it, at any price.
A codebase isn't the only time debt a company can incur, any process can be stuck in a suboptimal frame because no one wants to sign off on the time it would take to make it right.
The problem is usually finding a balance between "Let's hack some suicidally awful crap together quickly to see if we even have a market and then fix it when we have real income, except everyone knows we won't so it will be a permanent drag on the business" and "Let's build a beautiful extendable maintainable paragon of elegance and purity and ignore the fact that it'll take three years when we have six months of runway."
Too far in either direction will kill you. The sweet spot is between those extremes, and finding it is extremely difficult.
It's unhelpful that there isn't a word to describe aiming for that balance, never mind hitting it.
For companies, whether to use debt or equity to finance their balance sheet is just a technical decision. Either way, you have to pay the cost of capital.
(Ie even if you finance your project from equity and not from debt, it still has to be better for your shareholders than just giving them the necessary capital back via a stock buyback.)
A company can have debt as a permanent feature of its balance sheet, just like equity.
Funny enough, I suspect from a corporate finance point of view, technical debt should actually be called 'technical equity', because technical debt only gets expensive when your project takes off. If you never end up using that piece of code, the technical debt never has to be paid. But it gets more and more expensive, the more successful your project is.
Just like selling 50% of your startup to an investor (as equity) gets more and more expensive (in retrospect), only if your startup really takes off. Debt stays the same price, whether your startup is middling or goes to the moon.
This reminds me: if you went to a farm and actually 'picked the low hanging fruit first', they would likely fire you. The fruit higher up on the tree typically ripens faster, so should be picked first. (But the phrase as a metaphor is fine, and everyone knows what it's supposed to mean.)
Code quantity is always dependent on how well the person making this judgment understands the software. While I'm sure that everyone will agree that there are some clearly better ways of doing things, they sure as hell won't all agree on what these clearly better ways are.
One person's pile of garbage is the next person's perfect implementation with easy to understand procedural logic.
Please take note that I'm explicitly not saying that any implementation is better then another. I'm just trying to convey that the term technical debt very much depends on the mindset of the person looking at the implementation
You wanna build something? You may over-invest (too much debt), invest just right (manageable debt) or wait until it's too late (the paragon you mention).
Debt is a nasty word and it's meant to be but like some other bad things if you know what you can manage you can come out on top. People take loans all the time because they want to achieve that sweet spot you mention.
Taking on debt is not inherently good or bad, it's context dependent.
I feel it maps to technical debt very well.
Unfortunately I've become a bit disillusioned that we can reclaim the conversation to be about the optimal level of quality, and what tradeoffs are acceptable.
Office bullshit language seems to have strangled nuance so hard that I'm now sure that most of these conversations are useless and we'd better spend our focus on finding and working with mature adults that don't need that much convincing
Building without foundations, driving blindfolded, etc, could be better metaphors everybody can agree upon. If you're talking with a CFO, talk about high leverage (as for derivatives.)
Debt can be a permanent part of your company's capital structure just like equity can be a permanent part. Or do you have a plan to buy back all outstanding stock?
(Yes, real world debt in the form of bonds a due date, when you have to roll it over. But that's an accident of history. Instead companies could also sell perpetual bonds and put options on those bonds for the same effect.)
In finance terms, loosely speaking debt is the part of your capital structure whose cost is fixed in nominal terms. Equity gets the remainder of your income stream.
About high leverage: the more of your income stream you parcel out for fixed payments, the more you 'concentrate' your equity and the variability of the residual income it gets.
(Overall, I blame tax systems that give preferential treatment to debt over equity. Roughly, you can pay the capital cost of your debt with pre-tax money, but the capital cost of your equity comes out of post-tax money. Put them on equal footing, and you'll solve quite a few problems.)
What is technical debt today might actually be (considered) no debt at all later on (or even from the beginning, in the extreme case you're building something for once only), for multiple reasons.
The context matters a lot, and begets a more elaborate discourse than just "that's technical debt", which in itself means little of the possible or mandated actions.
(edited to refine)