Ward Cunningham originally came up with the metaphor of technical debt to “sell” the notion that the costs of refactoring code “up front” significantly outweigh the costs of having to spend time “down the line” building additional features on a code base with restricted extensibility. He used the metaphor of “debt” at the time because the people he was trying to convince were finance guys and he wanted to connect with them in a language they could understand.
If you need to “sell” the same fundamental idea but the metaphor of technical debt is not doing the job, presumably it is because the people you’re trying to convince are not finance guys. In this case it’s worth searching for a new metaphor which your target group can easily relate to.
Here’s an a simple idea of how to create a different metaphor:
A young guy, let’s call him Mike, gets his first paid job and decides it’s time to move out of his parents house and into his first flat. To start with Mike takes a spacious but simple room where he can sleep and keep his stuff but where he needs to use a shared bathroom with other tenants in the block.
After his first pay raise, Mike decides it would be nice to have a bit more convenience by having his own washbasin instead of using the one down the corridor. He calls up somebody to help him implement this and although they advise him that it’s best practice to build an enclosed bathroom where the washbasin can be installed, he decides for the less expensive option of installing it next to his bed.
Time moves on and Mike gets a promotion at work at which point he starts to think “This convenience and privacy thing is great! I think I’ll get a shower in here as well!” So he calls up the washbasin guy and starts to discuss options. Now the washbasin guy again provides some lower cost and higher cost alternatives but this time is quite insistent that the higher cost option of building a standalone bathroom is the right thing to do because it will give Mike the option of installing a WC and bathtub in the future. Mike thinks long and hard about this - as well as the cost of building the bathroom, there’s also the cost of moving his washbasin in there as well. And he’s not even sure if he’s actually going to want a WC or bathtub anyway. After thinking it over for a couple of days Mike decides to take the washbasin guy’s advice and get a standalone bathroom built in. “There’s some extra cost in doing it now” he reasons “but it will be worth it in the future as I’m pretty sure now I’m going to need a WC or bathtub and I want to avoid the cost of having to relocate both my washbasin and shower from the living room.”
This story has a happy ending. The alternative (less happy ending) sees Mike opt to install his new shower next to his TV and later he’s forced to shift both washbasin and shower to his bathroom anyway.
In this metaphor the washbasin guy (i.e. the development team) is recommending the creation of a standalone bathroom as well as the relocation of existing amenities (i.e. a refactoring of the existing set up) to prepare for the installation of a WC or bathtub (i.e. development of future features).
It’s quite a domestic example, but hopefully it helps you think of others more applicable to your domain.