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 widely read paper on lean construction, 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 idealize 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. -----