right; very inexact metaphor.
It's only helpful because code doesn't LITERALLY get consumed, in the sense that if you want to run a piece of code 1000 times (ever) you need 1000 copies, and you have one less every time you run it, or every one hundred times you run it a copy disappears or whatever, like a bag of chips that disappears when you eat it, batteries that get used up (after one full discharge with nonrechargeable batteries, after a while with rechargeable ones), or paper cups as in my example. Literally it's (in reality) very durable, it just becomes inappropriate or stop working or being effective because of the context, not the bytes themselves, which don't deteriorate. It doesn't deteriorate or disappear like a consumable good does, you don't need to buy another bag of it when you run out, it seems to be a bag of something that never runs out: so it seems obvious that if you're going to build a bag of something that never runs out, why not make that something absolutely perfect, you know?
It leads to engineers buiding everything like a ship (durable good) and coding nothing (or sys-oping) nothing like something consumable that they cannot see as using forever.
of course the metaphor is inexact:
any line of code you have on a reliable medium is in the same condition (literally the same characters, literally 0 difference) as when it was last written or updated.
Consumable goods get consumed or deteriorate, but code seems to "be forever" i.e. subject only to the license imposed on it and not its physical quality; this quality leads to overengineering, given the mentality that since it will be available forever, you might as well code it "for forever".
What I'm suggesting is that sometimes it's useful to look at code as though it were bags of manure (consumable) instead of a lot of land you or apartment/house you own in perpetuity.
This is just for resource allocation/investment decisions an engineer is making. A typical example is that it is VERY hard for an engineer to say, "I will write this in this one language/framework that I know really well, and is totally inappropriate, in 10 minutes, it will be like a paper cup. Then I'll direct resources elsewhere, and when I need a glass I will throw this cup away."
The tendency is to say "I can't fortify this paper cup, it doesn't scale, so 'why build sand castles'..."
I am saying that a consumable good (sand castle code) is often very appropriate given resource restrictions. It is also often VERY inappopriate, as when people do not own a dishwasher and tableware, but buy a bag of plastic and a bag of paper plates every week and throw it out every week. (People do live this way.)
It's a delicate balance; this is one tool in many in your arsenal for deciding where to allocate your resources. I should also specify that renting a durable good might be more akin to subscribing to a web-based service or whatever. Again, all these are analogies to help you make good time and resource investment decisions, and think of something in terms that are appropriate. It's easy to throw out a paper plate if you bought it once as hosting a very rare party that temporarily overloaded your capacity. It's very hard for engineers to realize that sometimes it's time to write that same paper-plate code and throw it away without ever washing it (investing more coding into it or trying to engineer a scalable architecture into it after the fact). Things to know about what you're doing up-front so you can make informed decisions and stick to them as your "household" evolves.