Why New Analogies For Software

I am going to compare developing software to a community writing epic poetry, not because I think you all have experience in community poetry writing, but because I think you don't - and your imagination can supply you with the sorts of contradictions, trade-offs, and issues I am interested in.

AlistairCockburn in SoftwareDevelopmentAsCommunityPoetryWriting


Wiki has spawned (and in some cases debunked) many NewAnalogiesForSoftware. This page attempts to pull together some answers to the question why.

DisciplineEnvy has the original WardCunningham "I don't believe it", referring to high falutin' traditional analogies, and his canny proposal of the journalistic analogy to keep us all closer to ExtremeHumility. There follows some useful, early discussion of the issues.

ItsOnlyaMetaphor also takes a slightly different view from this page, concisely emphasising the limitations of metaphors.


From AppropriateWikiTopics (on whether discussion of diets or other such topics are appropriate on Wiki):

It's surely worth applauding almost all new proposals for analogies for software and exploring them. Part of exploring an analogy is examining the parallel domain - at least to some degree - to assess both the strengths and the limitations of the analogy. It is one of the charms and the strengths of the Wiki community that this has often been done pretty well, with some basic humanity and humour as well as a serious desire to improve this "informal history of programming ideas".

In my view this is precisely what did NOT happen sufficiently earlier in software history with the civil engineering, architecture and building analogies, as these became embedded in the mindset of the software industry before it managed to attain any kind of identity of its own.

I've felt this with increasing force for over ten years. For discussion of one non-traditional analogy that I've espoused that has only recently begun to receive greater attention see AnalogiesFromMusic.

My general point is that because software is so intangible it's absolutely right for us to be big on analogies. But the industry desperately needs balance from over-enthusiastic and erroneous application of a few that are so hackneyed that we've even forgotten that they are only analogies. The way forward I'm proposing is to spread the net a lot wider, learn what we can from the combined insights but do the job of assessment and damage limitation in each domain much more thoroughly.

Pushing any analogy to ridiculous extremes to show its limitations normally also has the useful side effect of being very funny. Better a good laugh now than thirty years of pitiful, unfruitful practice to follow. -- RichardDrake


Unconsciously, presumably, a fishing analogy has crept into your statement. "spread the net wider". We can search for new analogies, but half-seriously, I suggest we also observe the metaphors we lapse into. -- CayteLindner

Acute observation of mixed meta-metaphors also has the useful side effect of being very funny. In fact I'm always inclined to explore more than half seriously any analogy that presents itself from 'chance' words. - RichardDrake.

Doesn't mean that Freud was right about that other stuff though. -- BasilFawlty?

See Gareth Morgan's essay on http://www.mgeneral.com/3-now/98-now/110398gm.htm for the importance and utility of metaphor in management. I believe that many of these points carry over to software. His "Images of Organizations" is apparently worth reading too but can be hard going.

I'm kind of metaphor driven, but I can't imagine explaining anything non-trivial without resorting to a metaphor -- PaulHudson

Also see Douglas Hofstadter's FluidConceptsAndCreativeAnalogies for discussions about the utility and limits of analogy.


New analogies? Absolutely. SoftwareIsaNewThing.


Someone once suggested the analogy of MovieMakingAsSoftwareDevelopment?. This is an analogy that stuck for me. Consider some of the attributes: the many people, technologies, project complexity, developed in pieces and then integrated, reviews, cost, schedule, one time work, stays around forever, artistic creation, and probably many other similarities. --MikeBarton


EditText of this page (last edited May 25, 2000) or FindPage with title or text search