the other does so in LIFO (last in, first
out) order, respectively.
Even if this looks like an everyday
thing for most programmers, the moment you choose to use a stack instead
of a queue, you are deciding how to explain your program. The stack is a very
good metaphor for the collection of
items that a program works with, because it tells a future reader of the program in which order to expect the items
to process. You don’t even need to read
how the stack is implemented, since
you can assume you will get the items
in LIFO order. This is why types are so
important in computer science—not
types as in static type checking of programs, but types as the concepts used
to describe programs: persons, users,
stacks, trees, nodes, you name it. Types
are the characters that tell the story of
your program; without types, you just
have operations on streams of bytes.
The goal is to find the right metaphor
that describes and explains a problem. As explained earlier with the
queueing theory example, a cognitive
leap was needed to go from tasks that
have to be processed in a certain order
to understanding that this is a queueing problem. Once you manage to
make the cognitive leap, all the mathematical tools from queueing theory
are at your disposal. Graph theory
is filled with examples of mundane
tasks that, once converted to a graph
problem, have well-known solutions.
Whenever you ask Google Maps to get
you to your destination, Google translates your problem to a graph representation and suggests one or more
paths in the graph. Graphs are the
right metaphor, understood by mathematicians and computers alike. Are
there other instances of problems
that seem difficult but that can be
solved by finding the right metaphor?
The distributed-systems literature
has a very interesting one.
In the late 1980s Alan Demers and
his colleagues from Xerox tried to find
a solution to database replication in
unreliable networks. They classified
their algorithms as “randomized,”
explaining them by using the rumor-
mongering metaphor: a computer
would tell two other computers about
an update, then each in turn would
tell two other computers about the
update, and so on until the informa-
tion was replicated across the system.
This metaphor gave way to a new area
of study called gossip algorithms. The
gossip metaphor makes the idea easy
to explain, but the Xerox team was
still lacking the mathematical tools
that would help analyze the effective-
ness of the algorithms.
During their research, they discovered another metaphor related to
their problem: epidemics. They understood their algorithms replicated
data the same way in which an epidemic disseminates across a population. By using this new metaphor,
they got immediate access to all the
knowledge in The Mathematical Theory of Epidemics,
1 which fit their work
like a glove. Not only did they name
their paper “Epidemic Algorithms for
Replicated Database Maintenance,”
they also took the nomenclature of
that discipline to explain their algorithms. It was a matter of finding the
right metaphor to get access to a new
world of explanatory power.
Do we really use that many metaphors
in programming? Let’s take a look at an
example from the distributed systems
literature (metaphors are in italics):
Whenever nodes need to agree on a
common value, a consensus algorithm
is used to decide on a value. There’s
usually a leader process that takes care
of making the final decision based on
the votes it has received from its peers.
Nodes communicate by sending
messages over a channel, which might become congested because of too much
traffic. This could create an information bottleneck, with queues at each
end of the channels backing up. These
bottlenecks might render one or more
nodes unresponsive, causing network
partitions. Is the process that’s taking
too long to respond dead Why didn’t it
acknowledge the heartbeat and trigger
a timeout? This could go on, but you
get the point.
A Story in Code
Programmers must be able to tell a
story with their code, explaining how
they solved a particular problem. Like
writers, programmers must know
their metaphors. Many metaphors
will be able to explain a concept, but
you must have enough skill to choose
the right one that’s able to convey your
ideas to future programmers who will
read the code.
Thus, you cannot use every metaphor you know. You must master the
art of metaphor selection, of meaning
amplification. You must know when
to add and when to subtract. You will
learn to revise and rewrite code as a
writer does. Once there is nothing else
to add or remove, you have finished
your work. The problem you started
with is now the solution. Is that the
meaning you intended to convey in the
Thanks to Jordan West and Carlos
Baquero for our discussions about how
metaphors permeate computing, and
for their feedback for this article.
First, Do No Harm: A Hippocratic Oath
for Software Developers
Phillip A. Laplante
Coding for the Code
Friedrich Steimann and Thomas Kühne
A Nice Piece of Code
George V. Neville-Neil
1. Bailey, N. T.J. The Mathematical Theory of Epidemics.
C. Griffin and Co., 1957.
2. Baker, C. (Ed.). What a programmer does. Datamation
(Apr. 1967); http://archive.computerhistory.org/
3. Carr, N. The Shallows. W. W. Norton, 2011.
4. Demers, A., Greene, D., Hauser, C., Irish, W. and
Larson, J. Epidemic algorithms for replicated database
maintenance. In Proceedings of the 6th Annual ACM
Symposium on Principles of Distributed Computing,
5. Gleick, J. The Information: A History, a Theory, a Flood.
6. Lakoff, G. and Mark J. Metaphors We Live By.
University of Chicago Press, 1980.
7. Shannon, C. E. and Weaver, W. The Mathematical
Theory of Communication. University of Illinois
8. Yorgey, B. Abstraction, intuition, and the ‘monad
tutorial fallacy.’ https://byorgey.wordpress.
Alvaro Videla ( alvaro-videla.com; @old_sound)
works as Lead Architect for a major Swiss company.
Previously, he was a senior software engineer at Apple
and a core developer of RabbitMQ. He is the author of
RabbitMQ in Action.
Copyright held by owner/author.
Publication rights licensed to ACM. $15.00.