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.