At the risk of getting downvoted I'm going to ask this anyway.

What are your favorite metaphors for technical concepts?

My most recent one I used was when a customer didn't understand why we would have to charge them for switching out one mapping api for another.

My metaphor was: If you had a heat pump at your house and then bought a gas furnace you couldn't just plug the electric wires in the furnace and expect it to heat your house.

+8  A: 

I don't like metaphors. They give people an illusion of understanding when they still have no clue. Then they try to reason from the metaphor, draw incorrect conclusions, and have high confidence in these incorrect conclusions. I prefer to describe things as they are, but vastly oversimplified, with a few disclaimers thrown in to the effect that I am vastly oversimplifying. Dijkstra gave a very good explanation of the dangers of metaphors in a truly new field in On the cruelty of really teaching computing science.

i wish i could upvote more than once!!
I'm not sure I understand, can you provide a good metaphor? `).
Liran Orevi
IMO, metaphors are for quick understanding of the concepts and I really believe in that. As 'Javier' said in his last comment, all can learn the intricacies of the working of "assembler" and then 'tell the compiler to tell the processor' to do something we expected!! But how many years will that take to start the basics of programming!! A postbox metaphor, instead, will merely take half an hour to explain the basics. :)

Working on a computer program is like gardening. If you nurture it, and tend it, and trim it, it may grow into a beautiful thing.

Cristian Libardo
Does it actually serve as a metaphor? To be one, it should actually "take you somewhere". This is a feel-good sentence, but what's the point?
Adriano Varoli Piazza
+19  A: 

My personal favorite technology (reverse) metaphor:

“Computer science is no more about computers than astronomy is about telescopes.”

--Edsger Dijkstra

Bill the Lizard
if only more programmers thought the same way...
Mitch Wheat
+3  A: 

My favorite metaphors are the ones that are like the worlds best built bridge that has the nails-across-the-chalkboard sound going constantly in the middle:

It not only takes people from the place that they were to where they need to be, it also doesn't offer them any encouragement to stay there, either, since that would defeat the whole point of the metaphor.

I didn’t immediately understand what you mean but you’re right. Richard Dawkins emphasizes the same point in “The Selfish Gene” (and elsewhere).
Konrad Rudolph
A metaphor about metaphors? You win the Recursive Rambo badge, Sir! :)
I think it's a simile.
Adriano Varoli Piazza
+4  A: 

Two metaphors that I like are “pipe” and “stream” because they are very rich and facilitate teaching enormously. They not only make it easy to convey the function in layman’s terms, but they also allow to delve further into the topic, including such hairy issues as leaky abstractions.

Let me illustrate. The “stream” metaphore can be taken quite literally as a little river in which I throw small fragments of bark on which I've written separate letters. Somewhere else, a friend is standing on a bridge and fishing out the floating fragments to reassemble the message I've sent.

This metaphor works excellently in many regards (e.g. there’s a data flow direction, data is distributed in discrete parts, there’s a reading and a writing end, data has to be encoded and decoded …). However, it is also obviously flawed: what if said friend misses a fragment? What if I run out of bark? What if some of the bark is washed ashore on the way? All these are difficulties that I’d have to consider in the real world.

Now, when I implement streams in software (or hardware), I actually have the same problems. Of course I won’t run out of bark but if, for example, I stream data over my WI-FI, there are a lot of external influences that have an impact on the signal quality and thus on the secure transmission of the data. These have to be addressed as well.

Joel writes about leaky abstractions in his excellent article.

Konrad Rudolph
+27  A: 

I must differ with Glomek.

We who have been dealing with computers for a while (myself, 35+ years) tend to forget that we swim in a sea of abstractions that other people can find difficult or impossible to get their heads around. People learn through communication and communication depends on having common concepts (and words for those concepts) between teacher and student.

Analogies are a powerful way to introduce a new, alien concept to a beginner. They start with something that is already understood by the student and then tie it to the thing being learned. It does not have to be the baby-steps method of teaching described by Dijkstra (with whom I don't always agree, particularly when it comes to teaching), but it does have to be comprehensible to the student. In fact, a really good analogy can leapfrog the student to a new place from which many other concepts can be taught.

/end mini-rant

Here is a teaching tool I have used to help students understand the ideas of memory, labeling, and assignment.

Consider the statement:

x = x + 1

It looks like an equality statement that couldn't possibly be correct. Just telling them it's "an assignment statement" doesn't penetrate with many people. I have found a mailbox analogy to work about 95% of the time.

It goes like this: You are at the post office in front of a wall of mailboxes. The mailboxes have numbers on them (you could go into memory addressing if it was appropriate, but it's probably best to leave that out unless someone asks for a little more detail). One of the boxes has a label on it: 'x'. The statement "x = x + 1" means "take the current contents of the box labeled 'x', add '1' to it, then put the result back in the box labeled 'x'"

Often, about 60% of the students immediately go, "Oh. That's pretty straightforward." For the remainder, you could have 4 or 5 cardboard boxes. Write 'x' on a sticky note and put it on a box. Write '1' on a piece of paper ... You get the idea. Seeing this very concrete representation of memory, and that the names are 'labels' on that memory, means that this thing they have been hearing about for years, 'memory', is now nothing but a bunch of boxes you can store stuff in. Simple.

You can elaborate on this by putting multiple labels on the same box, or putting special pieces of paper in some boxes that say 'don't use me, go get/set the value of some other box', thereby demonstrating pointers. You can also demonstrate type mismatches by putting a picture in a box and then ask a student what it means to 'add 1 to a picture'. Etc, etc.

This may sound like simplistic, but in 1/2 hour or less and you have given your students a real, usable model of one of the most fundamental concepts there is.

Peter Rowell
Excellent example. After learning C, I was perplexed why many people found pointers confusing; later I realized that I found them easy mostly because I had mentally constructed a box analogy myself, which simplified things greatly.
my experience is totally reverse. having known the basic principles (assembly in my case) makes pointers just a comfortable syntax for a perfectly natural case. no metaphors needed. i know what i'm telling the compiler to tell the processor
But how did you get to the point where you knew "what i'm telling the compiler to tell the processor"? It's possible that your first words were "load a; test_and_branch c; ...," but most students can't even spell von Neumann Machine, let alone relate to it. That's what teaching is all about.
Peter Rowell
Sometimes i think i'm an alien myself. I can't remember moment when i figured out how 'x=x+1' works. Like it has been obvious always.
Arnis L.
@Amis: +1 for the comment. It struck me that I never realized how strange and mathematically inconsistent x=x+1 is, until the day when I came across Erlang which disallows it :-)
Vijay Dev
The main point to get is that the = sign may look like "equals" but it is being used for a completely different concept. It was an unfortunate choice of symbol by an early language (Fortran?) which was copied by later languages like BASIC and C and now we're stuck with it. Other languages have made better choices for an assignment symbol, such as an arrow.
@Vijay - you either completely destroyed any hope of me ever wanting to touch Erlang, or made me want to go learn it next week. I can't decide which at the moment :)
@DVK: Erlang is a nice language to learn! I just read a few chapters of Programming Erlang by Joe Armstrong and was awestruck !!
Vijay Dev
luckily, i started with pascal, where it's x := x+1 ... :)
@back2dos: Agreed. Assignment is so fundamentally different from equality they really should have done something like that in other lagnuages.
Peter Rowell
@Peter - bravo for the use of metaphor in your introduction ("sea of abstractions"). 1+
+7  A: 

Building construction is a very useful metaphor when explaining to non-technical people why certain changes to an application are expensive when other changes are not. Swapping out a color on a web site is like changing all the carpets on a floor in a building whereas changing screen flow or how data is chunked through a procession of pages is like adding a new floor to the building. Metaphors that give you a visual, concrete image help people with abstract concepts.

+6  A: 

Not a favorite analogy, but certainly a notable bad one:

The Internet is a series of tubes.
Yes. And if you don't understand those tubes can be filled and if they are filled, when you put your message in, it gets in line and its going to be delayed by anyone that puts into that tube enormous amounts of material, enormous amounts of material. Yes, _enormous_ amounts of material!
all metaphors have this problem when you don't destroy them immediately. people think they understand but stay with the analogy and go on making false assumptions. like filing the tubes
My staff sent me an e-mail 5 days ago and I got it yesterday!
Robert Fraser
@David - Don't waste SO's bandwidth. The internet is not some truck you can just dump stuff on.
+1  A: 

When dealing with people who know nothing about technology or software/programming/computers/etc I find metaphors helpful. I certainly understand things better when someone explains them in a different context.

Something I use internally alot is "They gave us plans for a motorcycle and expected a car"


"They told us to build a car but didn't tell us what color to make it, how many doors it should have or how much it should cost."

Your second affirmation is just asking for "And why exactly didn't you ask them about that?
Adriano Varoli Piazza
We always have to ask those questions when we don't know enough. That would bring up something similar to: "They wanted a 4 door but when they saw it wanted a bus instead."
+13  A: 

Programming is like sex - if you make a mistake, you'll have to support it for the next eighteen years.

Sherm Pendley
I'm debating if I can use this in my next product planning meeting.
+18  A: 

Throwing more developers at a project won't necessarily make it faster.

"You can't make a baby with nine women in a month"

CAD bloke
Andreas Grech
But you can make 9 babies in 9 months! :)
Arnis L.
That's true. That makes you're average yield one per month.
Cristián Romo
Heh I use this one all the time at my current company except I say you cannot put 9 pregnant women in a room for one month and produce a baby. I have passed around the "Mythical Man Month Book" to 4 managers each of which laughed at me... /sigh
@Arnis - You can also make a baby with 9 guys and a woman, and 9 months. It's not pretty.
+3  A: 

Jelly may not have the same meaning in the US - I think they use "jelly" for what we call jam here in Australia. Jell-O may be a better term.

"Using regular expressions is like nailing jelly to a tree."
"Using regular expressions is like trying to train a cat".
Nailing jam to a tree is just as hard.
Adriano Varoli Piazza
+14  A: 

I'm currently using this one as my mail sig. Keep in mind it's not meant to advocate violence, it just shows the mentality of those people who think XML should be used for everything.

"XML is like violence.  If it doesn't work, you're not using enough of it".
My God, it's beautiful.
Hooray Im Helping
@paxdiablo - that's the best quote I've ever read... ever.

A good one:

Software Projects as Rock Climbing

+6  A: 

Pointers are a problem area with a lot of students. One way that I found to get the concept though was like this. A pointer in C is like having someone's address written on a piece of paper. The paper is the pointer variable, and their address is like a... well, an address (only this time it's a memory address). Having the piece of paper with someone's address on it is not the same as being at their house, but it tells you where their house is. If you go to the address on the paper, you'll be at their house. It's the same in C. If you go to the address that the pointer holds, you'll be at the value or object that the pointer refers to.

Bill the Lizard
And if you try to visit their house after it's been torn down-- you might run into trouble.
Scott Wegner

Not a favorite. But many people try to use Bridge building as a software metaphor.

Bridges, Software Engineering, and God

+5  A: 
            _                                           .----.   . - .
PROGRAM  (PRO'-gram') [n] A magic spell cast over a     |C>_.|.:' .:.  .
computer allowing it to turn one's input into error   __|____|__ `:.  O_/
messages.    [vi] To engage in a pastime similar to  |  ______--|   \/M
banging one's head against a wall,  but, with fewer  `-/.::::.\-'   _/ \_
opportunities for reward.                             `--------'

Yes, I bang my head against a wall almost daily.

+15  A: 

My favourite one is do with having multiple copies of the same data lying around:

"A man with one watch always knows what time it is.
But a man with two watches never knows."

Peter M
+30  A: 

I'm quite pleased with the metaphor I eventually came up with for the difference between value types and reference types.

I think of reference types as being like web pages. What you have in your hands is a way of getting to the information (the URL) and lots of people can see the same page. If someone edits the page, everyone sees the changes.

I think of value types as being like printed documents. You have the actual words in your hands (rather than just a way of getting to them). If you copy the document (with a photocopier) those copies are entirely separate - if I give you a copy then scribble on my original, you don't see my changes.

Jon Skeet
Three cheers for this metaphor, it's great. Making references understood is one of the biggest problems I face as a TA at university. I'll try your explanation. Incidentally, it shows that everyone (who uses the Internet) already knows and understands references and doesn't realize it.
Konrad Rudolph
Seconded.I'm going to consider using this :)
Dalin Seivewright
That's definitely a Shakubuku (a swift, spiritual kick to the head that alters your reality forever).
Even Mien
Had no problems understanding this. Had problems remembering and be able to predict which one to expect. `System.String` just make it worse (started with .Net).
Arnis L.
@Joh - Everyone doesn't necessarily see the edits, since some still have the page loaded. For that problem you could use an Ape server setup for some Comet. Get some polling going on and refresh the page when it's updated. Now the metaphor is technically corret :)
+1  A: 

Not a favorite analogy, but certainly a notable bad one:

The Internet is a series of tubes.

Well, the analogy isn’t bad at all. It just shows that when arguing in metaphors, you’ve got to be extra careful to understand the underlying concept, else you make a complete fool out of yourself.

Mathematically, a network is a series of tubes of limited capacity. Most of the theory behind network analysis, reachability, bandwidth calculation, distribution etc. relies on mathematical descriptions that can be applied without any change to tubes of different width through which you direct (say) a stream of water. An interesting application of this is the maximum flow problem.

Of course, none of this makes the Stevens’ stupid use of the metaphor any more justified. Stevens most probably just repeated some stuff he’d been told without even trying to understand it because he’s not forming any sort of coherent argument.

Konrad Rudolph
+1  A: 

Programming is like sculpting marble: art achieved by a tedious, sweaty craft.

+1  A: 

So I constantly make up my own metaphors. I blame it on my lack of ability to remember tons of technical terms. I'm much better a theory and concept than definitions of things.

We've been stuck on comparing our company's software development to a bakery this week. Our product offers are the different "cakes." Our business development guy was trying to tell me to use X technology when Y would have been a much better technical solution so I said to him "You can't tell me to use hot sauce in our Angel Food Cake."

+4  A: 

From Pattern-Oriented Software Architecture 2 (Schmidt et al):

A real-life example of the Monitor Object pattern occurs when ordering a meal at a busy fast food restaurant. Customers are the clients who wait to place their order with a cashier. Only one customer at a time interacts with a cashier. If the order cannot be serviced immediately, a customer temporarily steps aside so that other customers can place their orders. When the order is ready the customer re-enters at the front of the line and can pick up the meal from the cashier

+2  A: 

Like most technophiles, I have to support the IT needs of a range of family and friends, some of whom are a bit 'off the pace'. Frequently they confuse and misuse simple terminology, including the components of a computer and their roles:

Thus a computer can be considered like a kitchen -

The oven is like the processor; the more hobs/ovens (cores) you have, the more you can do at once, but accordingly more energy is used and more heat is generated.

The work-surface is like RAM; the more space you have, the easier it is to complete your tasks - if you don't have enough, you have to constantly swap the various elements you are working on, in and out of some sort of temporary storage. When you finish in the kitchen, the surfaces in the kitchen are wiped clean - the work-surfaces are not used for longer term storage.

The cupboards/refrigerator are like hard-disk space; they are for semi-permanent storage of ingredients (data) - when you need to work with certain ingredients you must take them out of the cupboards and load them onto the work-surface before you process them. When you have finished processing your ingredients, you place them back in the cupboards for longer-term storage.

At the simplest level, this analogy particularly highlights the difference between 'memory' and 'hard-disk (space)' which I noticed was a common problem. You could stretch the analogy further if you wanted to cover optical media (tupperware and packaged ingredients) and extractor fans (noise vs function)... and god only knows what else.

+12  A: 

RAM is like your desk space; hard drive space is your bookshelf space.

A big (full) hard drive and small RAM is like working in a library with loads of shelf space and a very small desk - so many books to choose from, but you can only have 1-2 open at a time.

Running out of disk space is like running out of shelf space - you can't get any more books (= apps / games / videos / MP3s) until you've got more shelves.

Oh, and when your system crashes, it's like the cleaner putting all your books back on the shelf and throwing away all your notes... your apps & games & stuff are OK, but your work is gone. Saving your work is like filing your notes away on the shelf (where the cleaner won't bin them!)

Dylan Beattie
Excellent - sometimes after I explain the difference between hard drive and RAM, I still get blank stares. Now I have a back up explanation.
Keith Bentrup
+8  A: 

Somebody (non-technical) asked me:

What does error on line 79 mean?

My response:

Imagine you're my mechanic; I call you and ask: "What does the blinking light mean?"

I'm going to need a little more information...


Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Citation Needed:

+1  A: 

From an article I wrote on my blog a couple of years ago. I was trying to explain SSL to my eight-year-old:

Me: If I want to send a message to another computer, I write the message on a kind of postcard, with the address of the other computer on it, and then I send it. The postcard goes out, sometimes on a wire, in this case through the air –
Ryan: Like radio waves?
Me: Exactly. Then the other computer receives the postcard, checks the address, and figures that the postcard is for him. Then he reads the message. But, if there's another computer nearby, it can look at the postcard too, even though it's got someone else's address on it. So if I want to send a secret message to a computer that's my friend, I don't want that other computer to be able to read it. So, I take the data on the postcard, and mush* it all up, and change it, and make it look funny. My friend knows that it's mushed up, and it un-mushes it and gets the original secret message out. But the other computer doesn't know this, so it looks at the message and says "Huh? What's that mean?"
Ryan: <giggle>
Me: When we first start talking, I tell my friend "Hey, I'm going to mush up this data, and here's how I'm going to do it." and I give him some stuff that allows him to un-mush the message — that's called the "handshake".
Ryan: Like this? <shakes my hand>
Me: Yes, just like that. It's a way that two computers say "hello, I'm going to send you some mushed data, here's how to un-mush it".
Ryan: That's cool.

* – Important note: Note that "mush" as used here rhymes with "bush" or "push", not "hush".

Graeme Perrow
Note that I didn't get into what certificates are and how they work, which is kind of integral to SSL. That's tomorrow's lesson. Class dismissed.
Graeme Perrow

An old one.. but this pattern can never be explained better
Starbucks Does Not Use Two-Phase Commit

Teja Kantamneni

To help my schoolmate understand functions and parameters in PHP, I likened it to adding bananas, milk et al into a blender and having it make banana milkshake, and she understood it right away :)


I liked a metaphor given by my non-technical friend, referring to my hacking laptop not being equipped with the most recent all-handling flashy codecs for multimedia, when we ended up watching movies on it.

He said:

"Well your computer is not like ours. It's a meat mincer, right?"

Couldn't say it better.

Wojciech Kaczmarek