Martin Fowler brings up the problem of using metaphors to describe software development - his point applies to any metaphor though - you can only bulld metaphorical bridges so far before they end up over open water:
As regular readers of my work may know, I'm very suspicious of using metaphors of other professions to reason about software development. In particular, I believe the engineering metaphor has done our profession damage - in that it has encouraged the notion of separating design from construction.
As I was hanging around our London office, this issue came up in the context of Lean Manufacturing, a metaphor that's used quite often in agile circles - particularly by the Poppendiecks. If I don't like metaphoric reasoning from civil engineering, do I like it more from lean manufacturing?
I think the same dangers apply, but it all comes down to how you use the metaphor. Comparing to another activity is useful if it helps you formulate questions, it's dangerous when you use it to justify answers.
So as an example - one of the principles of lean manufacturing is the elimination of inventory. This leads to the question of whether there is an analogous item to inventory in software development.
As soon as I read that, I realized that I had heard the term inventory applied to software development before - I finally realized that it was in Scott Ambler's talk at XP Brazil a couple of years back:
Metaphor from this morning - the data (dba) community is packing for Antarctica. Unfortunately, the rest of us are traveling in the desert or the jungle
Scott used that in describing what kinds of things you put in a backpack - depending on what kind of hike you are planning to take. So going back to Martin's question - is that a useful metaphor? Well, it does make you ask questions along the lines of will we need it? In that sense, I guess it's useful. The difficulty is, the answer to that question is going to differ based on who you ask. Like anything else, whether you need a given thing (up front documentation being Martin's example) is going to be a matter of opinion. Software development is still a field where you need to apply consensus rules a lot.