I think you're arguing against people using the phrase "technical debt" as a criticism, but those people are missing the point.
Technical debt isn't a perfect metaphor, but there's an aspect of it I think you're neglecting - the interest payments.
The point about debt isn't that you'll have to pay it back [1], but that you pay an ongoing cost until you do. In the technical debt case, the ongoing cost is opportunity cost - the initial quick hack may make it harder to evolve the code, or you may have to spend time fixing bugs instead of adding features.
As with financial debt, if that ongoing cost doesn't matter - because the payoff outweighs the compounded ongoing cost, or because you can offset the ongoing cost with other sources of cash flow / bandwidth - then taking the debt was the right call.
If you abandon the project (declare bankruptcy) then you never have to pay off the debt :)
If you "make it big", though, someone eventually will want to pay it off. Either you make it big by becoming a successful business, in which case your time horizon extends, and at some point the interest payments compound enough that you don't want to pay them any more. Or you sell to someone else, in which case they have the same problem, and (if they're smart) they should have paid you less because you sold them a liability along with an asset.
[1] Most financial debt has a maturity date, so eventually you do have to pay it back, although not if your lender is willing to indefinitely roll over. Technical debt generally has no maturity date, so you really don't have to ever pay it back!
nothing personal, but turns out you happen to be totally wrong. :) we can just look through examples until you realize this.
It is like saying if I sell you a luxury mansion in the Hamptons that comes with nice hedges, for $1, I've really sold you an $800 interest payment, since you'll want to keep paying a gardener to trim the hedges, since if you don't it will hurt the price of your property long-term. you want to retain the value.
Do you see how considering the $1 as coming with an $800 interest payment (until you replace the hedges with gates at even greater cost) is a totally wrong way to consder what has just happened?
The fact that someone (you) will want to pay something doesn't make it anything close to debt. It's an unhedged (heh) call option.
I think I see where you're going wrong here. We need to put some numbers to it.
Suppose you can make $20 if you spend $15 adding a feature. Obviously you should do it, right? You'll make $5. So you do.
Now the customer comes back and says the new feature doesn't work in some edge case and they won't pay the $20 unless you spend another $15 fixing it. At this point the original $15 is a sunk cost that you can't get back and you're presented with the original scenario again: Spend $15 to make $20. So now you've spent a total of $30 to make $20. This can repeat arbitrarily many times, putting you even further into the hole each time, until you recognize that hidden future costs mean that you're actually spending far more than $15 to make that $20.
If I can choose to pay full price for a luxury mansion or pay $1 for the same mansion, of course I should pay $1. That choice is not usually available, either in real estate or in software. More likely, I'm choosing between a studio for $200k and a 4 bed for $1m (adjust for regional house prices), or a cheap fixer-upper vs an expensive new-build.
The point of the debt analogy isn't to think about which parties are involved in the transaction; it's to think about the various kinds of costs involved in a decision, and the timescales over which they are paid.
From that point of view, if I can't afford the $800 hedge maintenance, then I shouldn't buy the mansion, even for $1. The strict analogy with debt breaks down a bit because I'm not paying you the $800, but it's still an ongoing cost I have to bear.
Edit to clarify, I'm still not saying debt is always bad. If I enjoy DIY and expect to have spare time, the cheap fixer-upper might be a great investment.
Technical debt isn't a perfect metaphor, but there's an aspect of it I think you're neglecting - the interest payments.
The point about debt isn't that you'll have to pay it back [1], but that you pay an ongoing cost until you do. In the technical debt case, the ongoing cost is opportunity cost - the initial quick hack may make it harder to evolve the code, or you may have to spend time fixing bugs instead of adding features.
As with financial debt, if that ongoing cost doesn't matter - because the payoff outweighs the compounded ongoing cost, or because you can offset the ongoing cost with other sources of cash flow / bandwidth - then taking the debt was the right call.
If you abandon the project (declare bankruptcy) then you never have to pay off the debt :)
If you "make it big", though, someone eventually will want to pay it off. Either you make it big by becoming a successful business, in which case your time horizon extends, and at some point the interest payments compound enough that you don't want to pay them any more. Or you sell to someone else, in which case they have the same problem, and (if they're smart) they should have paid you less because you sold them a liability along with an asset.
[1] Most financial debt has a maturity date, so eventually you do have to pay it back, although not if your lender is willing to indefinitely roll over. Technical debt generally has no maturity date, so you really don't have to ever pay it back!