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.
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.
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.
My personal favorite technology (reverse) metaphor:
“Computer science is no more about computers than astronomy is about telescopes.”
--Edsger Dijkstra
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.
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.
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.
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.
Not a favorite analogy, but certainly a notable bad one:
The Internet is a series of tubes.
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"
or
"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."
Programming is like sex - if you make a mistake, you'll have to support it for the next eighteen years.
Throwing more developers at a project won't necessarily make it faster.
"You can't make a baby with nine women in a month"
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".
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".
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.
Not a favorite. But many people try to use Bridge building as a software metaphor.
_ .----. . - .
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.
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."
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.
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.
Programming is like sculpting marble: art achieved by a tedious, sweaty craft.
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."
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
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.
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!)
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: http://www.codinghorror.com/blog/archives/001230.html
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".
An old one.. but this pattern can never be explained better
Starbucks Does Not Use Two-Phase Commit
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.