TITLE: A Metaphor Lost
AUTHOR: Eugene Wallingford
DATE: March 17, 2006  9:57 AM
DESC: 
-----
BODY:
If you've read my blog for long, you know that I like
a good metaphor.  We can often learn something useful
about one system by considering it as another kind of
system and seeing what kind of questions this new
conception leads us to ask.

"Software engineering" is a metaphor, even if many folks
take it for granted as reality.  I've never been all that
fond of the metaphor, though we certainly can learn
something about how to develop software by considering
how engineers make things.  But my experience with
commercial engineering projects on university campuses
has never felt like how I do or might build software.

My latest experience -- with the renovation of an old
building on campus as a new home for my department --
has illustrated yet again why we should not limit
ourselves to engineering as the model for how we make
software.

This building project is now over six months late.  Each
time the schedule is adjusted, it seems to fall behind
again within the month.  Communication among the various
units responsible for, and affected by, project has been
abysmal.  Changes were made to plans, but these changes
did not propagate to everyone who needed to know and as
a result work plans were often out of sync.  Sometimes,
folks knew about a change but had no incentive to find
out how the change affected what they should be doing
-- so they didn't.

My favorite example of this was when a service closet
was converted to a server room for my department.  The
change was made in conjunction with building architects,
and the updated drawings for the building now showed a
"server room".  At least some of folks responsible for
building infrastructure were aware of the change, but
they either assumed that the change didn't affect them
or figured they didn't want to know how it would.  Plans
proceeded as they were, with no provision made for the
necessary cooling or power to the room.  As the time
came for us to move in, we increasingly pressed for these
changes to the room, which would now be costlier to
implement, both in time and money.

I know, this is only an anecdote, one experience by one
person with one project.  It hardly serves as a suitable
logical basis for arguing that a seemingly useful idea
should be discarded.  But this experience is representative
others I have had, and also representative of experiences
had by many others on this and other campuses with building
construction and renovation.  It is a now banal joke on
campus that we should add months to each target date we are
given for the completion of projects.

Don't get me wrong.  These are not bad people.  I think all
are trying to do their jobs well under demanding circumstances.
But as Mary Poppendieck reported in a
<A HREF="http://www.poppendieck.com/construction.htm">
   widely read paper on lean construction</A>,
the system doesn't work in a way that makes smooth, timely
projects all that likely.  Projects are complicated, plans
are tightly coupled, and pipelines are sensitive to small
changes in expectation.  That's just how the world really
is.

This is one of the dangers inherent in metaphor: unreality.
It is easy for us in software to <EM>idealize</EM> other
disciplines and how they work.  One result is that we beat
ourselves up for how we could do better is only we were more
like "them", for some broad spectrum of thems.  Architecture
-- isn't it just dreamy?  Engineering -- tough, rigid, clean,
controlled.  But we need to make metaphors with our eyes
carefully tuned to how the world really is in those other
disciplines, not only the ideas but the daily practices
and experiences.  Otherwise, we are bound to create
unrealistic expectations for how we do what we do, and how
well we do it.

And ultimately we lose out on the learning to be had from
the metaphor, because we will miss the opportunity to ask
ourselves the questions that will help us to understand
better what we do.
-----