What software analogies have helped you?

Question

I have often enjoyed the use of analogies in understanding a software scenario or problem.

For example, to understand the concept of public key encryption, the 'locked mailbox' analogy or similar is often used as an aid:

An analogy for public-key encryption is that of a locked mailbox with a mail slot. The mail slot is exposed and accessible to the public; its location (the street address) is in essence the public key. Anyone knowing the street address can go to the door and drop a written message through the slot; however, only the person who possesses the key can open the mailbox and read the message.

My question is:

What analogies have you used or heard of in your career that have given you that "Eureka" moment with a complex concept?

EDIT: If you have a good one, don't just state the name, please share with the group!

Answer 1

The HotBeverage analogy used in Head First Design Patterns, really helped me understand algorithm encapsulation (template method).

Basicly all beverages are made the same way.

  PrepareRecipe()
  {
      BoilWater();
      Brew();
      PourInCup();
      AddCondiments();
  }

The above Template Method defines the steps of an algorithm and allows subclasses to provide their own implementation for one or more steps.

Answer 2

For symmetric key crypto, I use the locked box analogy:

Open a box, put in the message, put a lock on the box. Anyone with the key to the lock can open the box, and read, replace, or steal the message. You can mail the box to someone - but you also have the additional problem of getting the key to the person securely.

A similar analogy can be used for key exchange:

Put a key in a box, and lock the box with your lock, that no one can open. Mail the box to Bob. Bob can't open the box, but he can put his own lock on it that you can't open, and he can mail it back to you. You take off your lock, and mail the box (locked with Bob's lock) back to Bob. He takes off his lock, and can open the box.

For classes, and this isn't the best analogy, I liken them to buckets of related information. Everything about a Giraffe. It has a name, a height, a spot pattern. It runs, eats and dies.

Answer 3

The mammals hierarchy (dogs, cats, humans, etc) to teach inheritance and implementation.

Answer 4

Interfaces: if it looks like a duck and it quacks like a duck, it must be a duck.

Answer 5

While not related to a specific software scenario, in The Mythical Man-Month, Fred Brookes expounds the idea of changing the traditional software development analogy of building software into one of 'growing' software.

His idea in this is to recognise that software engineering is, fundamentally, not building a thing as in a standard engineering discipline, but growing a software product in an iterative, organic fashion.

While he first proposed this idea in the mid-60's, when I first read it I realised both how true this is and how much we still - often subconsciously - consider software engineering in the same way as traditional engineering despite its many differences.

This 40+ year-old idea seems particularly relevant today with the increasing prevalence of agile methodolgies, and I'm amazed at the continued relevance of Brookes's ideas.

Answer 6

I liked the Object Thinking analogy of thinking of an object as a person with responsibilities instead of just a datastructure with some methods.

Answer 7

I really like the garden analogy. Code is a like a garden, it needs to be organize and maintain and if you don't do it then it will become an unmaintainable mess.

Answer 8

IMHO, analogies are ok only for explaining, not for understanding and never for planning.

To make any kind of choice, you have to think in the real terms of the problem; any 'layering' between it and your mental model, and you'll be losing some insights, or fail to recognise real limitations.

If you're thinking in terms of analogies, you don't really grok the issues.

Answer 9

What analogies have you used or heard of in your career that have given you that "Eureka" moment with a complex concept?

Can't think of one really, but comparing a computer virus with a ...virus is pretty explanatory!

Answer 10

One which I found quite good was from Jeff's recent post where he references an analogy/metaphor on technical debt attributed to Ward Cunningham.

Very useful in explaining to the layman the benefits of taking extra time on the correct technical solution up front.

Answer 11

When teaching someone about pointers, I use the analogy of the URL and the web page. I know it's another technology and most of these analogies aren't, but it's one that everyone is familiar with. If you tell someone that the pointer is like the URL and the thing pointed to is like a web page, it becomes a lot easier to comprehend what the difference is.

-Steve

Answer 12

This isn't something that gave me a eureka moment, but it is good for explaining to other people.

DNS is a telephone book. If you know someone's name, you can look up their phone number, and then you use their phone number to contact them. If you know their phone number, it's possible to do a "reverse" lookup to find out their name, but that doesn't always work.

Answer 13

The analogy of software construction with building construction.

I've come back to this one time and time again when trying to explain the purpose of outlining a plan before starting to code. A home builder doesn't jump in and start building a house before creating and analyzing the blueprints. Costs to remove a wall in the design phase is minimal in comparison to a wall that needs removed after the structure has been built. A home builder will install pre-manufactured windows because the quality of the product is higher than he could replicate for the same cost, similar to buying or using third party plugins or software.

The analogies I've found between these two subjects have been plentiful and helpful when dealing with none tech colleagues.

Answer 14

Me: I'm a web developer; she's the web designer (points to wife) 
Person: What's the difference? 
Me: She designs the light switch; I make sure the lights come on.

Answer 15

The analogy that Nicholas Carr uses in "The Big Switch" to compare the shift to cloud computing with the shift from local power generation to electric utilities.

Why is this analogy useful? It helps set expectations about the kinds of benefits (as well as shortcomings!) that a business can achieve by moving to a utility computing model.

How could this analogy be dangerous? It may also set expectations that cloud computing can be accomplished by "just plugging in" - it paints a picture of cloud computing that is not really achievable today (but hopefully will be in the medium term).

Analogies are by definition rather blunt instruments - they help orient people to a high level way of looking at things. They tend to break down pretty quickly when subjected to close scrutiny.

Answer 16

The Iron Triangle in Project Management theory. The balance between parameters of time, cost and scope of a project, where you can "pick any two" and the third has to be allowed to balance out.

Reading about this was like someone articulating something that I already sensed. Most projects are in jeopardy because of attempts to put the triangle in non-euclidean space.

Answer 17

Not strictly an analogy but...

My "light bulb" moment with writing SQL was when I realised I needed to let go of worrying about what the database was doing, and worry about what I wanted out of it.

It's the difference between giving the waiter detailed instructions on how to make your dinner, and explaining how you want your steak done and letting the kitchen sort it out.

(The related comment I make to people who insist on trying to reinvent sorting, grouping, and joins in Java, Perl, or TCL, is to explain to them that if they really have worked out how to do any of the aforementioned operations faster than Oracle, Larry has a job and a yacht for them.)

Answer 18

This describes pretty much why commenting is useful and why people don't like to do it

"Commenting your code is like cleaning your bathroom - you never want to do it, but it really does create a more pleasant experience for you and your guests." - Ryan Campbell

Answer 19

A programmer is like a librarian in a constant hurry. The faster he handles the returns of books by just throwing them somewhere, the more time it will take to find the right book for the next customer.

Answer 20

Analogies...good question!

Concerning technology:

interfaces are like contracts between systems. they contain promises and constraints (function signatures) and not the content (implementation) itself.

Concerning the process&teams:

The design problems and code smells made in a hurry or by laziness in software development are just like karma...they will definitely hit back in the future.

I like the broken window analogy from the pragmatic programmers book.