From what I can tell, the definition in the link you provided is precisely what you're saying it's not. He says this:
> The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.
So indeed, his definition of technical debt is explicitly that by rushing software development now you will slow down future development.
The specific software engineering task that caused him to develop the analogy was about rewriting some code to incorporate new learnings, but the analogy itself is clearly applicable to any software engineering task that could be deferred to the future (with a cost).
Right, and I think the example here is instructive. He's not talking about rushed, shoddy, buggy code. He's talking about not taking the time to implement the right design. The resulting code might work just fine and doesn't necessarily impose additional maintenance costs, but the design issues mean that every time you're adding or modifying a feature you have to do extra work to translate from the 'correct' theoretical design of the feature to the actual design.
Unfortunately, while managers are often happy with "it'll make page load faster" or "it'll increase uptime" as a justification for a project, and "it'll reduce bug reports" and even sometimes "it'll automate manual tasks", "it'll make development easier" can be a really hard sell. It sounds pretty abstract and I think some managers start to think that it's just an excuse. It's certainly hard to quantify the impact, especially if you're expected to do that in $/yr.
> The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.
So indeed, his definition of technical debt is explicitly that by rushing software development now you will slow down future development.
The specific software engineering task that caused him to develop the analogy was about rewriting some code to incorporate new learnings, but the analogy itself is clearly applicable to any software engineering task that could be deferred to the future (with a cost).