Do this metaphors really help anyone? To me it only obfuscates the situation. It doesn't give me any clarity. Honestly "technical debt" doesn't mean much to me and I've seen the words mostly being used as a shielding mechanism by developers who want to avoid discussing difficult topics.
> Do this metaphors really help anyone? To me it only obfuscates the situation. It doesn't give me any clarity.
To be fair, leaving aside how fitting or unfitting it is, the metaphor is too kind to cause any reaction at all.
If you say "we can take a bit of technical debt to get more work done today, we can always pay it off later", people would nod and move on. The reaction you get would be, at most, on the same level as someone watching TV news about a tragedy on a different continent ("Oh no. Anyway...").
But if you say "we can cook today's meals without washing any pots/pans/spatulas/etc and save time and money that way, we can just keep doing it every day until the first roaches appear", even though the message probably gets across way more clearly, you'd get a warning to watch your language and keep it appropriate, and how dare you compare the company to such a nasty restaurant.
"Our technical debt is starting to become too much" doesn't ring the same as "there's too many roaches and they are actually starting to get in the way of our cooking".
You're right, "technical debt" doesn't raise any sense of urgency. What people actually mean by technical debt is that there is a trade-off to be made: short-term gains at the expense of long-term costs. Your kitchen metaphor works beter because it conveys that message. But still metaphors usually end up in discussions about the metaphor and not the actual topic itself. It doesn't propel the discussion forward. I'd much rather prefer to discuss specifics instead of metaphors.
It can go wrong too, though. Like if the other party focuses too much on "human uses dirty pan" and interprets it as "dev uses bad IDE" because both pan and IDE are tools humans use, missing the point.
The metaphor was kinda improvised so I'm sure it has other bad parts. The way I thought about it was with the kitchen being the service or codebase, and the utensils being utils/functions/modules/etc. Nothing more. So I bet there's more ways this metaphor can break.
Seems like a similar thought to "Programming as Theory Building"[1].
The paper is well worth reading, but the TL;DR if you don't wanna: the "theory" of a program (how does it fit together? What extensions/modifications would work well, how should it evolve to handle new cases, etc.) is contained only in the mind of the coder; documentation, spoken explanations, etc. are attempts at describing that theory, but they are necessarily a lossy encoding of it. Certainly attrishing everyone who knows something about a codebase would be extremely foolish under Naur's argument.
Debt, I guess to me, is code deviating from a known better theory for it to follow.
The "attrishing" in your comment made me go looking, and Wiktionary [0] says the verb form "attrit(e)" exists and is likely a quite old backformation that has fallen out of common use.
I wouldn't quite say attrite has fallen out of common use, though it is by its nature rarely encountered. I certainly use it, and it's fairly common in certain fields (e.g. discussions of language attrition, ironically).