Analogies between computing and the real world are often ill-fitting, and taken too far. An accurate analogy can be useful to get the gist of something, but computing analogies are rarely accurate. The problem is that computing often isn’t really like anything else, so most analogies are doomed to fail. In this post I’m going to look at a few examples of computing analogies gone wrong.
Law
Trying to create analogies for computing (and properties of information) when dealing with the law is often unhelpful. I once supervised a class where some computing undergraduates were debating whether it is moral and/or legal to use your neighbour’s unprotected wifi to access the Internet:
Student 1: “Finding unprotected wifi is like finding a house with an open door. Sure, no-one’s stopping you going in, but it’s still burglary if you take anything.”
Student 2: “No, see, DHCP offers you an IP address. So it’s like finding an empty house with a welcome mat saying ‘take what you want'”
Their problem is that they tried to reason using a wonky analogy. A wifi network is not like a house: using someone’s wifi is not like stealing a physical object — you are not depriving them of a piece of property (you are using a service). A better analogy might be comparing unsecured wifi to finding a drinking fountain outside someone’s house — but even then, you will soon run into trouble. There’s no subsequent drinking-fountain analogy for what happens if a person browsers local machines via the unsecured wifi.
Similar problems arise when discussing copyright law for electronic media. There is no physical analogy where an exact perfect copy can be made for zero cost, so physical analogies are useless. The whole copyright-infringement-is-stealing argument is another example of a failed analogy: taking a copy does not deprive anyone of anything (except potential revenue). As the saying goes, you wouldn’t download a car, would you?
Car Analogies
Speaking of cars: it used to be a running joke on slashdot that people repeatedly made bad analogies to cars. Cars are not so far from computing: they are complex systems that require design, building, maintenance and allow tinkering. But so often the analogies go wrong. For example, here’s part of an attempted car metaphor by author Neal Stephenson, from his essay “In The Beginning There Was The Command-Line”:
Linux…[the developers] are making tanks. These are not old-fashioned, cast-iron Soviet tanks; these are more like the M1 tanks of the U.S. Army, made of space-age materials and jammed with sophisticated technology from one end to the other. But they are better than Army tanks. They’ve been modified in such a way that they never, ever break down, are light and maneuverable enough to use on ordinary streets, and use no more fuel than a subcompact car. These tanks are being cranked out, on the spot, at a terrific pace, and a vast number of them are lined up along the edge of the road with keys in the ignition. Anyone who wants can simply climb into one and drive it away for free.
So what’s gone wrong here? All these physical characteristics don’t translate very well: space-age materials doesn’t fit anything in software (what is he intending to refer to there?), and concepts like maneuverability are ambigious: is this referring to customisation (an advantage of Linux) or usability (at the time, a disadvantage of Linux). The concept of fast production of free tanks is an attempted analogy to the perfect copying of software and the cost-free nature of software. But as we’ve discussed, analogies between physical items and information are not really accurate. I think trying to use analogies here to make computing understandable harm more than they help: wouldn’t the time be better spent trying to explain the actual properties of computing?
Building
A popular discussion point is whether computing has matured/will mature so that software engineering is as straightforward and rigorous as, say, civil engineering. The idea commonly being that bugs in software are just a sign that we haven’t developed our tools to the point of physical engineering, while building a bridge is done reliably and safely every time. To quote Jeff Atwood’s article putting the lie to this comparison:
Software development is only like bridge building if you’re building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn’t exist five years ago.
The point being: software engineering is nowhere near similar enough to physical engineering to compare the two. The challenges and setting of developing software are unique compared to other engineering disciplines, because a computer program is nothing like a bridge. The challenges of programs are the elimination of bugs (i.e. bad logic) and the maintenance of code (e.g. easy refactoring, good organisation). The concepts of structural faults and maintenance in bridges are not the same: programs do not decay, programs have logic not steel.
Natural Sciences
I wonder if we also need to beware these comparisons when it comes to computing as a discipline. Physics and chemistry have largely separated into theoretical and applied disciplines. The theoretical side studies the properties of the physical world, and the applied side then uses this to build things. I think there is an expectation that computing should do the same. But I wonder if computing is again too different to the physical world for this principle to transfer. New theory can provide inspiration for new programming languages, which can in turn provide new avenues for theoretical investigation. Because computing does not study the natural world, and all of it is artifically constructed, theory and practice cannot necessarily be divorced in the way that they can for physics.
The Inevitable Dijkstra Quote
Dijkstra is over-quoted (because he wrote a lot, and had a lot of strong opinions), but for once I think the relevant quote is quite sensible (from EWD1036):
It is the most common way of trying to cope with novelty: by means of metaphors and analogies we try to link the new to the old, the novel to the familiar. Under sufficiently slow and gradual change, it works reasonably well; in the case of a sharp discontinuity, however, the method breaks down: though we may glorify it with the name “common sense”, our past experience is no longer relevant, the analogies become too shallow, and the metaphors become more misleading than illuminating.
Summary
The problem is that analogies are like… damn, they’re so tempting! I suggest that we don’t reach for the analogy too soon, especially in computing. Instead, try to explain the aspects you’re interested in directly. Concepts like free perfect copies, bugs or open source are not that hard to explain, but physical analogies for them fall down too often.
Academic Computing 
Good post, Neil. I’m wondering what you think about the possibility of good analogies? (I have a vested interest, in that I’ve just written an introduction to computing that’s basically all analogies.)
All analogies break down at some point, and yet I think they offer a powerful way to learn about new subjects. Especially if we consider computational thinking. The argument would be that some kinds of processes we encounter in our everyday lives are analogous to the processes we see in computing, because they’re fundamentally the same thing at an abstract level. Modularity, for example–I describe my building, my office, my bookshelf, and a book on that shelf in terms of a hierarchy of modules that makes it possible to organize activities and information in a comprehensible way. Or for a different example, I heard Sebastian Thrun on the radio today describing data in terms of Lego blocks: “Data comes in all shapes and sizes…” We need hooks on which to hang our intuitions.
I was thinking more about this yesterday. I think a lot of the problem with analogies is that people make the analogy, and then instead of throwing it away, they continue explaining via the analogy. For example, variables. One common analogy is that “a variable is like a box in which to store a value”. That’s fine, I think. But if you continue with that, and say “assignment is like putting a new value in the box” or “assignment copies a value from one box to another” then I think you run into trouble. Values are not like physical things: the idea of copying is not a good fit, and if you put a new value into a box, where did the old value go? Physically, it has to go somewhere, but in computing it can vanish.
Maybe the guideline should be that all analogies fall apart quite quickly, and the skill is to know to stop using the analogy before it breaks down. Your modularity example seems good, but, for example, if you then needed to explain that things can be in multiple modules, then obviously the physical analogy breaks.
I think this is exactly right, as well as your observation that information is different. Most of the analogies for information handling that I’ve tried out in the classroom or in writing are a stretch. In giving the variables-as-boxes analogy, I’ve been asked why you can’t put more than one value in the box. That’s a reasonable question, and my answer that it’s an arbitrary rule is very weak.
Thanks for the post; it’s given me something to think about.