Categories
Technical Communications Writing

Kill Your Darling Tech Analogies (Almost Nothing In Life Is Like A Car)

Over the years, I have come to fear and loathe most uses of metaphor, simile, and analogy in technology discourse. Interesting, helpful analogies are the exception rather than the norm.

What makes a bad analogy?

The main problems as I see it, are that the images people use tend to be:

  • Unoriginal and predictable. 9 times out of 10, it involves a car or traffic. (Seriously, have you tried a Google search for * is like a car?)
  • Hard to understand. How many people understand, in technical detail, how a car works?
  • Far-fetched at best, faltering and completely unnecessary at worst. Because not that many things in life are like a car.

Explaining an unknown with an unknown

Far-fetched is your smallest problem if you are able to get the first two right; be at least somewhat original and make it understandable to your audience.

Understanding is where you can’t afford to fall short, because for an analogy to be successful, at least one side needs to be well known to your audience, and both of them need to be familiar to you. You can explain something your audience doesn’t know by comparing it to something they know. Or you can give them new perspectives on something they do know by comparing it to something that might be new to them.

However, way way way too often, I see tech analogies that try to explain an unknown with an unknown. An audience that is already struggling to grasp a technology concept, is asked to wrap their brains around another concept that is somehow related to the first, in ways that shall only be fully revealed once they properly understand both concepts.

I’m not going to claim that it is impossible to pull such a dual explanation off. But it is very hard and requires the speaker or writer to realize that they must explain both sides of their analogy for it to work.

Ignoring cultural context is a related pitfall. For example, some traffic rules vary by country and continent, as do knowledge of and interest in sports. On this subject, I recommend Espen Andersen’s blog post on Pitfalls for the US speaker in Scandinavia.

Loving your analogies too much

The real problem with doing away with poor metaphors and analogies, though, is that as their makers, we tend to fall in love with them. I don’t use them a lot myself, but when I do, I can find myself struggling to make connections where few exist even as I realize it adds little value. William Faulkner adviced that writers kill their darlings. Analogies should be near the top of the hit list. Refusing to see past an analogy’s shortcomings can only hurt your case. Bad analogies are likely to leave your readership confused, annoyed, zoned out–or led down a ridiculous line of argument by a faulty analogy that devolved into a discussion on traffic rules when the subject at hand was copyright.

Analogies are the darlings of many a geek with something to convey, but there is little to indicate that the receiving end yearns for more analogies. In my experience as a tech writer, I don’t think I have ever seen a request for comparing technology to other things when users are struggling to understand something. One of the most common requests, on the other hand, is more and better examples.

Killing poor analogies in three steps

If you want to avoid unhelpful analogies, this is my advice:

  1. Don’t use a car or traffic analogy, unless traffic and cars are part of the subject matter at hand. There might be a fantastic car metaphor for what you’re about to explain, but if so, it has in all likelihood been done to death already.
  2. Pick an analogy where at least one side will make sense to the audience, and where both sides make good sense to you. Go with something you know well and can talk or write about in a compelling manner. Don’t try to explain Transport Layer Security by comparing it to a kevlar suit if you have a limited understanding of either. Competent audience members will see straight through it, and your analogy will have weaknesses that you can’t even know about.
  3. Test your analogy on as many friends or family members as you can dig up, trying to make sure they have a somewhat different skillset than your own. Ask for their honest assessment of your analogy: is it interesting? Do they understand it? Is it helpful?
    • If yes, you have an analogy that seems to work well. Now try to avoid overselling it. “With ready-made WordPress themes, giving your blog a makeover is as easy as dressing up a paper doll” is a reasonable simile, while “WordPress blogs are paper dolls” is taking it too far, in my book.
    • If no, kill it, and skip using an analogy altogether. A straightforward explanation accompanied by one or more relevant examples will be every bit as helpful as an analogy. Probably more.

10 replies on “Kill Your Darling Tech Analogies (Almost Nothing In Life Is Like A Car)”

Haha! Excellent comment #1. I do agree with #2, and I think the inadequacy usually stems from a combination of factors, the most prominent of which are the speaker or writer’s simultaneous infatuation with their own bad analogy and lack of understanding of their subject matter or whatever it is they choose to compare it to (or both).

I think an analogy that is a huge stretch can still be made interesting and relevant if the person using it is aware of its shortcomings. But that probably works best in the context of putting a new perspective on something known, rather than explaining something unknown. For example a technical writer telling a group of colleagues about how hula dancing or mountain climbing are like tech writing (randomly picking hobbies from colleagues that I am sure would be able to make interesting and entertaining connections almost regardless of subject).

In my work as a lecturer I try to avoid analogies at all costs. The reason is simple: There is nothing to be gained by introducing more ideas than absolutely necessary to an audience. Analogies burn valuable time and moves the focus of attention from the main subject of the lecture.

Unless used by a very professional speaker, it also gives the impression that the speaker is unsure of her subject – if you know what you’re talking about, why not talk about that instead of something else entirely?

Thanks for commenting, Vinish! I read your post, and I think you were making good points that to me got a bit lost in all the different analogies. I did find some of them easier to follow than others. Unsurprisingly, as I don’t drive, the car parking one did nothing for me. And in my book, emotional needs are for living creatures, I don’t think content can go through emotions and get confused about its own location, but users for sure can get confused about the location of our content and very often do.

Redesigning and rebranding turning content into a patched-up road resonates a lot better (although to avoid the traffic connection, I’d say it could be a patched-up anything, like a repaired garment where the seams are showing).

It seems to me you are trying to make a lot of very valid points all at once, and picking a different analogy for each of them. I think there are at least three potential separate posts in this for you. If going for it, I’d recommend focusing on one issue at a time, taking a little more time to state your case with examples and maybe include a pre-tested and approved analogy 😉 My two cents.

Almost a year later, I feel I want to share two more links relevant to the subject:

1. For a perfect example of a misguided car analogy, see the caption under the photo in this article: http://www.theguardian.com/artanddesign/2014/mar/31/ask-a-designer-switching-fonts-save-us-government-millions (and the body of the article elaborates on it further down). The analogy is actively unhelpful, bearing negative utility.

2. Eliezer Yudkowsky wrote extensively on the dangers of reasoning from surface analogies. This one shows how this kind of reasoning leads to failure in AI design: http://lesswrong.com/lw/vx/failure_by_analogy/

Leave a Reply

Your email address will not be published. Required fields are marked *