TITLE: Software Engineering Metaphor, Mythology, and Truth AUTHOR: Eugene Wallingford DATE: September 15, 2007 11:05 AM DESC: ----- BODY: We often speak of metaphors for software development, but what we are really talking about is a mythology. Until this morning, I forgot that I had already written about this topic back in September 2004, when I wrote Myth and Patterns about a session led by Norm Kerth at PLoP that year. I just re-read that piece and had two thoughts. One, what a great day that was! And two, I don't have much new to say on this topic after all. I was jazzed this morning to talk about the fact that software engineering is more a mythology of software development than a meaningful metaphor for doing it. Why jazzed? Recently I ran across a satirical fable entitled Masterpiece Engineering by Thomas Simpson, which appears as an appendix in Brian Randell's reminiscence of having edited the reports of the 1968-196969 NATO Software Engineering conferences. Simpson's satire made light of the software engineering metaphor by comparing it the engineering of artistic masterpieces. He wrote it in response to the unexpected tone of the second NATO conference, held in 1969. The first conference is famous for being where the term "software engineering" was coined, more as a thought experiment about software developers might strive for than anything else. But, as Randell writes, the second conference took some participants by surprise:
Unlike the first conference, at which it was fully accepted that the term software engineering expressed a need rather than a reality, in Rome there was already a slight tendency to talk as if the subject already existed. And it became clear during the conference that the organizers had a hidden agenda, namely that of persuading NATO to fund the setting up of an International Software Engineering Institute.
Show me the money. Some things never change.
However things did not go according to their plan. The discussion sessions which were meant to provide evidence of strong and extensive support for this proposal were instead marked by considerable scepticism...
I'm glad that I found Simpson's satire and Randell's report. I enjoyed both, and they caused me to look back to my blog on Kerth's PLoP session. Reading it again caused me to think again about what I had planned to write this morning. That old piece reminded me of something I've forgotten: myths embody truth. I was set to diss the engineering metaphor as "nothing but a story", but I had forgotten that we create myths to help us explain the ways of the universe. They contain some truths, sometimes filled out with fanciful details whose primary purpose are to make us want to hear the story -- and tell it to others. "Deep truths often lie inside stories that are themselves not strictly factual." So rather than to speak ill of software engineering, the worst I can say this morning that we became too self-important in the software engineering myth too soon. We came to believe that all the filler -- all of the details we borrowed from engineering to make the story more complete -- were true, too. We created an orthodoxy out of what was really just a great source of inspiration to find our own way in the challenging world of creating software. Maybe we have learned enough in the last forty years to know that much of the software engineering myth no longer matches our understanding of the world, but we aren't willing to give up the comfort of the story. What we need to do is to identify the deep truths that lie at the heart of our myth, and use them to help us move on to something better. I think Ward and Kent did that when they created XP. But it, too, has now reached an age at which we should deconstruct it, identify its essential truths, and create something better. Fortunately, the culture of XP and other agile approaches not only allows this growth; it encourages it. The agile myth is meant "to be shaped to its environment, retold in as many different forms as there are tellers, as we all work together to find deeper truths about how to build better software better." I'm still learning from a conference I attended three years ago this weekend. -----