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. People have suggested that up front documentation is such an analog. It sits there, producing no value, until you actually deliver some software that's based on it.

Here the metaphor is helping us look at our practices from a different point of view. It helps us to ask questions about what we do. Thus far I think a metaphor is useful.

The breaking point comes when people say: "we eliminate inventory in lean manufacturing, up front documentation is the equivalent of inventory, therefore we eliminate up front documentation". Now I agree we need to substantially reduce this kind of speculative documentation; but the rationale for doing so must come from thinking about the software development process, not from purely reasoning by analogy.