Whereas the concept we are trying to get across is: we have accepted some things that are less than ideal (code quality) in order to gain in another area (probably time to release). A tradeoff, and more importantly a tradeoff driven by concerns outside of engineering's domain.
I might agree that the term is overplayed and watered down, but any replacement has to include the role that the business side plays in the problem.
Like, when we were a small company we were delivering our stuff with metaphoric bicycles, because they are cheap and good for the environment.
Then we updated to motorbikes for faster delivery.
Now our customer base has grown, and we have a lot more stuff, so we are updating everything to trucks, and need time to dispose the bikes that we do not need anymore.
Then finally, we have become an international company and need to update to cargo planes.
And when they try to blame the engineers that it is their fault and they should have been using the biggest thing from the beginning, you can say: You do not buy a 747 to deliver stuff to you neighbor on the same street.
I'm sure it's not the final iteration of analogies we use to garner more budget or help clients understand that always pushing for the cheapest solution isn't the best idea. But I think it does a reasonable job. It abstracts away the finger pointing of "you coded it badly" vs "you never give us enough time to do it well."
Taking terms to a client like clutter, bad code, spaghetti code, and other more direct terms I've seen lead straight to uncomfortable questions about capability, experience, and so on.
I think if it's explained with the idea of compound interest it conveys the growing impact over time if it's left undealt-with, and it's an analogy most people are familiar with.
It's definitely easier to push back on taking a shortcut using the debt analogy than by saying it will force us to make their product badly and please pay us for the privilege.
I totally get what you're saying, personally I will always speak my mind and put my foot down where appropriate, I avoid working with people that constantly just push for more with less. Even then though people still often want things done and don't understand what they're asking for.
It's definitely better than the house-building analogy that causes eyes to roll so far back they roll out of the boardroom and down the hallway. Trying to explain how code complexity really works puts everyone to sleep and no one understands it anyway.
I'd be really interested in a compendium of boardroom analogies come to think of it. Could be a fun read.
With "technical debt" you could argue that business demands coming down to "I want it NOW" will lead to slower or more work later, and give management agency in determining if that is in line with the value they expect to gain.
With "technical clutter", the problem is moved to the devs: They could just have, you know, "worked cleaner" to begin with (nevermind we never gave them the time to do so). It's their own mess that originated by their decision, not the mess caused by PMs or customer expectations. And if the mess caused by mess-inducing management tactics becomes too big, management would just fire "bad" devs and hire some newbies.
So ... I do get where you're coming from. With normal people, the difference in meaning would lead to better understanding. But management has a large amount of non-normal folks.
This is the interest you pay. 'Debt' captures the problem of it being an ongoing cost.
You'd regularly clean a building you live or work in. You probably won't do the same to a building you have to enter once a year for 10 minutes just to go in to change a light bulb. Even if it's dirty or cluttered, the ROI probably isn't there.
Not all debt comes with terms that allow it to be paid off "from time to time". Most personal debt does, but the debt that corporations deal with often has very strict, inflexible payment terms.
Instead let's call it "technical clutter", because that is what it is.
It's the equivalent of an unclean workshop with broken and unused tools lying around. You trip over everything, you cannot find anything, your tools hurt you or slow you down.
Managers need to understand that technical clutter is central in hindering and slowing development. Not a separate account that is not affecting work.