> So yes, the core idea of technical debt resonates with developers, but not with business stakeholders.

I think that if this is the case, you are presenting it wrong. Business types are very familiar with the tradeoffs of debt financing, you have present it as being paid in effort vs. $ (which after all, have a close relationship) and they will immediately understand that a large technical debt means you can get less desired stuff done for the same input of effort. And then you collectively decide.

Agree you have to be careful about what you present as technical debt. If you need buy in from the business side, you don't want them thinking "that's just what they say when they want more time, it doesn't mean anything". It has to be pretty concrete.

I think we're largely agreeing, but a fundamental difference is that actual debt you have to pay back, and with technical debt you don't. So inherently you need to start discussing the trade-offs associated with the debt, and not the actual "debt" itself. Technical debt is not some external thing that we are forced to deal with.

unless its a perfect shining jewel - every piece of existing code constrains future development, until progress asymptotically approaches zero and development cost asymptotically approaches infinity

> every piece of existing code constrains future development

If that were literally true, then every new development would rationally necessitate a total rewrite of the codebase.

You might have meant that parts of the existing codebase would need to be changed to adapt to the new development, but as long as you've made a rational decision to keep using parts of the existing codebase, it must have been a net positive otherwise you'd just throw it all away.

In the contemporary tech industry, there's a pretty good chance that the managers who oversaw the decision to incur technical debt are not going to be the managers who make the call whether to "repay" it. It might not even be the same programmers. The "debt" metaphor makes a lot of sense when you're saying "you are asking for something that will incur a cost that we will later need to repay". It seems less effective when you're saying "your predecessor's predecessor asked my predecessor's predecessor for something that probably made sense at the time, but now we 'owe' some work on fixing the problem they left us".

The thing with actual debt is that you have to pay it back, because you agreed to do that in a formal way. That's not the case with technical debt. No one says you have to pay it back. That's why I think the metaphor falls flat when you use it with business stakeholders.