This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Analogies - What You Know That Ain't So
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
Like Martin Fowler, I'm "suspicious of using metaphors of other professions to reason about software development". But for different reasons.
The problem is that typically, reasoning about software development on the basis of analogy (which is what we really mean by "metaphor") goes in a certain direction: we compare software development with something we don't know really well - say, the construction industry, or the manufacturing industry, or the practice of accounting, etc. And then we use some clichéd insights about these mostly unfamiliar areas to buttress our well-worn, strongly-held convictions about software development, which we think we know well enough, thank you. Hence the perennial arguments: "once a building is erected it's incredibly expensive to make structural changes to it, so get your architecture right first thing".
The maneuver from a position of sketchy knowledge to one of smug complacency has little appeal to me - weakness shoring up weakness. It is a textbook illustration of the old saw that "it ain't what you don't know that kills you, it's what you know that just ain't so".
On the other hand, I know quite a few software practitioners who had (or still have) a completely different career, and real expertise in that field; one example that comes to mind is Dave, who originally set out to be a family therapist. Such people are entitled to draw all the analogies they want, I believe; such a cross-pollination of ideas is in fact key to the vitality of our field, and perhaps of any field.
So that's another combination - strength with strength. I'm a bit twiddler by vocation, so I can't keep myself from thinking of the remaining two. And in fact, we also use analogies to good effect when we discover the "real" truth about a field we didn't actually know that much about, and use that to put our software development knowledge in perspective. Reading about lean manufacturing or the Theory of Constraints woke me up to some problems actually relevant in manufacturing, as opposed to my mental picture inspired mostly by Charlie Chaplin in Modern Times. It also provided me with an abstract view of these problems, which was necessary, absent experience on a shop floor, to understand the narrative. And this abstract view in turn happened to have elements applicable to software work. That would be gaining strength from previous weaknesses of knowledge.
Lastly, I might expect a category where an analogy to something that we are particularly familiar with, an everyday experience maybe, illuminates unprobed questions about software development - unsuspected weaknesses. As an example, I particularly liked George Paci's way of subjecting the term "discipline" to scrutiny, as used in the expression "high discipline methodology", by way of an analogy to the everyday (for some of us) experience of driving a car - this was in a recent thread on the XP mailing list.
Previous Topic
