Thursday, October 15, 2009

when to use analogy

Analogy is a useful device when used to describe the things that we work on; but it is actively dangerous when used to describe our work itself.

When we're building software, it is useful to be able to say for example "it's like a library, where someone can make use of a feature and then stop using it so that someone else can use that feature" or "it's like a train, where there are just a few places where anyone can get on or where anyone can get off"

But when we use analogy to talk about our work, we invite misconception and misinterpretation. To say "writing software is like making a cake" invites misperception. Does writing software involve flour and sugar? Is there frosting involved?

Of course someone who says such a thing *probably* means that to write software one must do certain steps in a certain order-- but it is far better to describe the actual steps ("red, green, refactor" is not an analogy) than to invoke analogy, because analogy always misleads to some extent, and we have known for many years that the cost of failed communication on software projects is extremely high.


Joe said...

Language is always a tricky thing.

When communicating via analogy, we must ensure that what was heard was understood as intended.

That is true when building software, as well as when we talk about our work.

Matthew said...

I'll have to think on this. I'm tempted to say that analogy can be helpful when communicating with people for which we lack a common shared understanding, and can help build that understand.

For example, I'd say technical debt can be helpful to, say, communicate with a finance guy. However, when it's just us technical folks around the water cooler, we might be might better off just saying "dude, Joe took a lot of short-cuts to get to code complete. AGAIN. What's that all about?" and /dealing/ with the issues.

In those cases, in my experience, tech debt can become a blamy label and an excuse for sloppy thinking. So I think I agree with your sentiments, Chris, but I won't go quite as far as you do in conclusion.

Rick said...

Specificity is important. Dubbing a particular component layout "layer cake" limits the scope of the analogy to where it's useful and applicable. Start painting entire fields of endeavour with metaphors like "building software is like building a house", and you are in for trouble.

Michael said...

I disagree with your objection to using analogy to talking about our work. In fact, Chris, by your (highly appropriate, in my view) use of artistic endeavour as a metaphor for software testing, you apparently disagree too.

I appreciate the recognition of the risk in using metaphor, simile, or models, but we apparently can't live without them. The risks, to me, are twofold. One is the risk in failing to recognize how they work; the other is using in using a metaphor incorrectly.

To the first risk: a simile is in the form of an explicit comparison ("x is like y"). Implicit here is the fact that x is not y, but that x is like y in some factor, dimension or respect. Metaphor is different; metaphor says "x IS y". This sounds crazy, but the purpose is not to try to utter a truthful statement, but to create cognitive friction—to confront us with the task of sorting out how X is and is not like Y, the better to understand the differences and the similarities.

Northrop Frye talks about this The Educated Imagination, a book about why we have literature and literary speech. Metaphor, he suggests, is irrational but as Shakespeare says, "the poet, the lover and the madman are of imagination all compact". Frye says that by saying this obviously false thing—my love is a red, red rose—that our motive is to create a world that is completely surrounded and absorbed by the human mind.

To the second risk, Richard Lewontin provides a vigourous and coherent objection to misuse of metaphor. He's a cellular biologist, and his b
ĂȘte noire is the persistent idea that DNA copies itself. He says DNA doesn't copy itself any more than plans for a photocopier copy themselves; it's the cell machinery that does it. But note (as he does himself) that we can't live without using metaphors.

The problem, to me, is not in using analogy, models, metaphor, or simile. It's in hearing or saying "X is Y" and translating it into "X is like Y in every respect, and X is in no way different from Y". To me, that's misrepresentation or intellectual laziness.

You wouldn't want to throw the baby out with the bathwater. (And yes, that's a metaphor.)


---Michael B.

Chris McMahon said...

Michael's comment mostly stands on its own, but I do want to be clear that I do actually believe that making software in a certain very high-functioning and creative way is in fact a species of artistic performance, with no need whatsoever to resort to analogy, metaphor, or simile.

Analogy is appropriate for work that does not yet exist. But for work that we do, far better to discuss what actually exists than something removed from what actually exists.

Marlena Compton said...

Thanks for writing this. I work in an environment where analogies are tossed around like fish at Pike Place market(oops, I just used one) except the fish end up on someone's dinner table and the analogies are just coping mechanisms for not understanding technology.

Lately I've been reading about analogy in George Polya's How to Solve It. An important take away for me is that analogy works in two parts: 1.make the analogy 2.clarify how the existing situation DIFFERS from the analogy. In the case of my work environment step 2 is never followed so I'll hear the business people screaming something crazy like "we're baking a cake!!" for weeks. I wish they would add something like, "except that we're really..." After a few weeks, the analogy changes itself and we're baking a cake for a different reason because no one every bothered to remember why we were "baking" in the first place. The relationship and definition must exist in order for the analogy to be useful at all.

I say use analogies, but be very clear about WHY a particular analogy is being used. Unless the analogy is explained, what's the point?

TestWithUs said...
This comment has been removed by a blog administrator.