This question already has an answer here:
I'm in search of good language or metaphors to discuss the maintainability of code with non-technical folks (PMs, business sponsors &c).
In particular, I've recently created a few one-off, get-it-done-tonight, gets-the-job-done pieces of code. Everyone, including the internal sponsor, knew that we were saving a couple hours based on the premise that the code would be used once, for the immediate need, and not again.
Then the inevitable: "Hey, remember that thing we did? Let's do it again, but with these minor changes." Of course, the minor changes aren't so minor, all the more so because the code was written as a big ol' procedural nastiness hinging on assumptions about the environment. [Yes, yes, I know, avoid the problem in the first place. Don't write bad code. Write everything as if it will be maintained by someone else, or me years from now. That's a different question, though. This is after it's happened.]
So what are some good metaphors for the internal sponsor (non-technical) to quickly explain why the code isn't maintenance or minor-change friendly? The walls on a movie set: There's no garage there, it's just a door. -or- The doors are welded shut on this car.
How do you describe this continuum?
I want to find some terms for our group that will help talk about how much effort goes in up front and how that will improve maintainability: illustrating the trade-offs in "Do you want this tonight or do you want it maintainable?"
(In writing this up, I realize this might be the same as defining 'maintainable' for non-technical stakeholders. Seems like explaining loose coupling to non-technical types may not be the best way out of this. If you've successfully done that, how?)
Edited for answer: For now I will continue to use building construction metaphors. This will turn into the size and strength of the foundation: "Yes we can build that building on this, but we will need to rework the foundation to be larger and cover the right area."