> It is completely reasonable to consider the situation where, say, I give a farmer cash in return for some produce at harvest time to be a debt.
Being entirely-too pedantic about financial instruments: that’s a commodities future. Financially, it’s not a liability, it’s an asset: you’re owed something. It’s not really a good comparison to technical debt, which is at the very least clearly a financial liability of some kind — something that makes your company worse-off for having it.
I think the author of the article, meanwhile, was interpreting “debt” to specifically be shorthand for “a loan taken out against future earnings.” Loans a company takes out give them both a short-term asset (cash flow) and a matching long-term liability (loan repayment.) Which seems kinda-sorta like what “technical debt” is motioning at: you get short-term gains (working code) but a long-term liability (the need to rewrite said code when its lack of robustness or unmaintainibility causes it to break down in the face of scaling challenges.)
But this analogy is still pretty far off-the-mark, because:
1. You need to pay back a loan, or bad things happen to your company; but you won’t necessarily need to pay back technical debt — sometimes, despite your company scaling as a whole, the relevant software component just never needs to scale, and so it that particular technical landmine just never “goes off”;
2. loan repayments are predictable, and involve entering into contracts where you either conscientiously repay the debt month after month with low premiums, or you fail to make payments and the loan comes due. Technical debt is nothing like this; there’s no counterparty forcing IT companies into a default situation of paying down their tech-debt little-by-little. (Wouldn’t that be great?)
Thus, a loan against future earnings is likewise a bad analogy for what technical debt “is.”
Dredging around in finance for a more exact analogy for technical debt, a very close one might be writing and selling call options against your own company, where your share price hasn’t yet reached the strike price for these options. You would be raising short-term capital, but creating a future liability — in that when your share price hits the strike price (i.e. when your company grows), people would then have a growing incentive, commensurate with the growth in your share price over the strike price, to exercise their purchased call options by buying at the agreed strike price; and then some of those people — an unpredictable subset of them — would turn around and dump the resulting shares on the market at market value, lowering your share price.
IMHO, the analogy is pretty okay because both scenarios are the same sort of “setting up a bomb for yourself that may go off at an unspecified time into the future, but only contingent on your company being successful, where you’ll have more resources to deal with it” problem.
But on the other hand, you can’t really defuse having sold call options, in the way that you can “pay down” tech debt. (I guess you could try to buy back the call options — but the holders are under no obligation to sell them back to you. Whereas tech debt has no such willful resistance to being fixed.)
So even this analogy, though better, isn’t a perfect one.
Truly, though, although we can’t say we know what technical debt is specifically, we can probably be pretty explicit by just generalizing the term: all of what we call “technical debt” is in fact some kind of financial liability (in future engineer-hours needing to be spent.) So perhaps “technical liability” is, although vague, the best we can do.