MetaWar

Recently Robert Anderson and David Anderson (who are not directly related) both posted about metaphors that made them angry.  Robert's angry about computing cycles | electricity.  David was tweaked about home building | agile methodologies.   (Hair splitters will want to point out the difference between an analogy and a metaphor - but the terms overlap and I had to choose one if my choice bugs you, do a global search and replace...).

I think an issue here is that all metaphors are misleading in their own way.  The dictionary is of no help to us here.  The definition of metaphor is mechanical and has no tolerance for individual points of view.  But as the near-flaming discussions that took place when David said home construction isn't always the best metaphor for agile methodologies or the pointed refutations of Robert's cohort Dan's metaphorical assertions of Nick Carr show (more Nick) -- there's a lot of assumptions that come with any metaphor.  And no two things are ever exactly alike - so all metaphors are just invitations for communication breakdown.

The problem is - everyone loves a good metaphor. Extreme Programming, an agile methodology is, in fact, reliant on metaphor.  This has its benefits and costs.  But the costs themselves lie in the strength of the metaphor.

Metaphorical strength is subjective.  Metaphorical strength is cultural.  Metaphorical strength is based on breadth of knowledge.  In fact, only a tiny fraction of a tiny percent of all the world's population would know what the hell computational cycles or agile methodologies are ... or even electrons for that matter.

The tranferrence of any one thing's attributes to any other thing is always risky.  One thing is never an other thing.

The aptness of a metaphor needs to fit the audience with whom it is being shared.  In David's case, the application of agile methodologies to home building was made by a speaker who just plain didn't know how to frame his story.  In the comments to David's post and later in Glen's post, I try to make that distinction. 

In short, the analogy (metaphor) didn't work in context.  He decontextualized it by removing it from the laws of physics and common sense.  You can't build a home by building a kitchen first.  But you can certainly apply agile principles to other elements of home building and thereby construct a better story.

Robert is trying to show that the value of compute cycles in a utility context doesn't equate to power generation.  Which I will take as true because I trust Robert implicitly.  But Nick's point that centralized systems can produce value in a context similar to a utility is still likely valid.  His metaphor was employed to invoke a vision based on a perceived similiarity - but Robert fears the communication of a dissimilarity as a similarity.

And this is where the differences in perception / world view come into play.  Both people are right, but they are right in different ways.  It's sort of the relativity theory of interpersonal communication ... depending on their location two people can have the different perceptions of an event and both be correct.

Photo: Kenn Kiser

Tags: agile agile programming agile methodologies metaphor analogy social psychology

Comments

[Robert Anderson]

Thanks for the trust; however, I cannot accept only being right in different ways, I must be absolutely right!

[Glen B. Alleman]

Thanks for the reference. As one workig in the hard goods (Carbon-Carbon spacecraft and the software that flys them), agile processes have great merit. They are not applied in excatly the same way an XP software project might be inside some place like MSFT. But incremental, iterative, partial delivery is pretty much the common practice before full rate production.

It may not be the case of residential home - I can't say about that - but pharms plant construction runs along the lines of incremental, iterative as well.

It would seem to me there is lots to be gained by sharing "analogies" and "metaphors" to see where they over lap and where they don't.

[Dan Ciruli]

Jim - the problem I see isn't so much with drawing metaphors as much as drawing conclusions from them. Electricity and compute cycles have some things in common, but that doesn't make them identical. And while a metaphor can have some superficial illustrative meaning, more often than any deeper comparison breaks down rather than instructing.

Plus, Nick Carr is totally wrong about servers.