Communication In Software: Metaphorically Speaking

Metaphors are used extensively in technical fields. I was pondering some basic questions about them, such as:

• What is a metaphor?
• What is a metaphor not?
• How does metaphor aid in understanding unfamiliar concepts?
• What is the value of metaphor in human communication?
• What are the limitations and risks of metaphor?
• Metaphors that have become defining terms
• Metaphors people may have forgotten are not defining terms
• What new metaphors have been adopted to describe emerging technologies and capabilities?
• How much weight should we give metaphors to help us understand technologies and capabilities (new or old)?

What Is a Metaphor?

According to Wikipedia:

A metaphor is a figure of speech that directly refers to one thing by mentioning another for rhetorical effect. It may provide clarity or identify hidden similarities between two ideas.

And according to Merriam-Webster:

A figure of speech in which a word or phrase literally denoting one kind of object or idea is used in place of another to suggest a likeness or analogy between them (as in drowning in money); broadly : figurative language

And per the Free Dictionary:

A figure of speech in which a word or phrase that ordinarily designates one thing is used to designate another, thus making an implicit comparison, as in “a sea of troubles” or “All the world’s a stage” (Shakespeare).

You can find definitions online as easily as I. It’s as easy as pie…which is a simile, not a metaphor.

What Is a Metaphor Not?

There may be different ideas about what a metaphor is, but one thing is clear as crystal: A metaphor is not literally the Thing it describes. A metaphor usually captures some salient aspect of a Thing, but never comprehensively or definitively defines or describes the Thing. A real Thing is both more and less than the metaphors that describe one or another aspect of it.

The Bard suggests “All the world’s a stage.” In a loose, poetical sense, one can say we enter, play our parts, and exit. But a stage is less than the world: Many things happen in the world that don’t happen on a stage. And a stage is more than the world: A focused microcosm of life can be played out in a controlled way there, in a way that doesn’t happen outside the theater, so that we can examine it and try to comprehend it. Our lives may resemble the parts played by actors, but only to a limited extent. In fact, the more closely we look at the world, the less it resembles a stage.

A metaphor is meaningful up to a point, but the metaphor is not the Thing. The same metaphor that helps us gain an initial grasp of a new subject can lead us far astray from a deep understanding of that subject, if we cling too closely to the metaphor.

It’s interesting to me that in the software field we habitually sling buzzwords around as if we were talking about real Things, when in fact the buzzwords are only metaphors. Often it seems as if people who learned about a Thing via a metaphor don’t realize they’re talking about a metaphor, and believe their familiarity with the metaphor is in fact a proper and deep understanding of the Thing.

Similarly, people may be led astray into analyzing, extending, and perfecting a metaphor at the cost of ignoring, undervaluing, or even undermining the Thing it represents. More on this later under the heading of “risk.”

How Does Metaphor Aid in Understanding?

People tend to learn by example faster and more easily than through formalized abstractions, particularly when they are trying to gain an initial understanding of an unfamiliar subject. Once a person has a general grasp of a new concept, they are in a position to comprehend the formalized abstractions that provide deeper understanding of the subject.

Take the idea of quantum tunneling, for instance. Particles do not literally “tunnel” through energy “barriers” the way a naked mole rat tunnels through dirt, but thinking about it in those terms helps us get a basic mental image of how alpha particles can escape atomic nuclei, or how protons can fuse together in the sun’s core despite their mutual electrical repulsion.

Armed with this basic mental image (there’s another metaphor – “armed” – they’re everywhere, like the plague (that’s a simile)), we can more readily understand the Heisenberg Uncertainty Principle and start to use it to build more extensive mental models of quantum phenomena:

Δx×Δp=h4π

What is the Value of Metaphor in Communication?

Metaphors offer a shorthand way to discuss complicated topics. If we had to speak a paragraph’s worth of words every time we mentioned a given subject, our conversations would be stilted, boring, and confusing.

In discussing the delivery capacity of a software development team, we can say “velocity” and everyone knows we mean the amount of work the team can complete, on average, in a given time interval, and we don’t mean, literally,

va=v+v02

“Velocity” in software development doesn’t mean velocity. It’s only a metaphor. But it’s much easier to use in conversation than “the amount of work the team can complete, on average, in a given time interval.”

What are the Limitations and Risks of Metaphor?

A metaphor can serve as a useful mental hook (metaphor: there are no actual hooks in our brains) when we need to gain a basic understanding of an unfamiliar topic, but trouble ensues when we forget it’s a metaphor and start to think of it as the Thing it represents. We start to perfect the metaphor, extend it beyond its intended meaning, and gloss over (metaphor: we don’t apply gloss) aspects of the Thing that don’t quite line up with the metaphor itself. Once we start to do that, we lose track of the Thing.

Consider the example of velocity as a metaphor for the observed delivery capacity of a software development team. Many people focus on the measurement itself rather than on the team’s delivery capacity. Are we counting Features? Stories? Story points? Tasks? Estimated hours completed? Something else? What should we count? Why isn’t velocity increasing? Should velocity increase? Seems like it should; wouldn’t that mean the team is improving? Maybe we should set a target for velocity, to help the team improve! And we should standardize the sizing and forecasting methods of all the teams in the organization so that we can roll velocity up to an executive dashboard. And…and…

In my book on Software Development Metrics, I list common anti-patterns for each metric. There are more anti-patterns in play surrounding velocity than any other metric. Why? I think it’s because people have come to think of velocity as a real Thing. In physics, it’s real. In software development, it’s only a metaphor. The moment we forget that, we start to waste time and effort focusing on the metaphor instead of the Thing. At that point, the value of metaphor breaks down.

Metaphors That Have Become Defining Terms

We use metaphor to describe a great many things in the software field. In some cases, the metaphor has become the name of the Thing.

• software
• code
• bug
• scrum

I’m sure you recognize those terms. They refer to distinct concepts in the software world. We can’t even refer to “the software world” without using one of them.

There was a time when there was no such thing as “software.” People programmed computers by listing orders for the machines to carry out. As more computational demands were placed on the machines, the programs became more complicated to write. It became cumbersome to enter individual instructions by hand.

Grace Hopper became one of the first people to develop compilers. The first one was a program loader that could organize pre-assembled subroutines into a sequence. Step by step, compiler by compiler, she and others of the time discovered the principles necessary to design robust compilers that could translate human-readable statements into machine-executable ones.

There was no definitive name for this new sort of Thing. To distinguish programs from physical products, or “wares,” they coined the term software. The new word was a metaphor for a Thing that was not a “hard” ware. Now the word is a defining term for that category of Things.

The word software was originally seen as derogatory; not something to be proud of. Engineers distrusted software, and preferred to have logic built into physical products. Richard Battin, who led the development of the inertial guidance system software for the Apollo program, writes:

The MIT Instrumentation Lab had been designing software for the Apollo onboard guidance system even before the word software was invented. I still remember the first time I told my wife that I was in charge of “Apollo Software”. She exhorted me: “Please don’t tell any of our friends!” (Some Funny Things Happened On the Way to the Moon, 1989)

There was no word to describe the people who wrote software, either. When Margaret Hamilton was hired as a “programmer” on the Apollo project, neither she nor her employer were entirely sure what the word implied about one’s job duties. In the course of the work, she gave meaning to the word.

Computers execute software in “object” form, but humans write it in “source” form. The source form of software is called code. According to Merriam-Webster, the word code can mean:

1 : a systematic statement of a body of law; especially : one given statutory force
2 : a system of principles or rules moral code
3 a : a system of signals or symbols for communication
b : a system of symbols (such as letters or numbers) used to represent assigned and often secret meanings
c : coded language : a word or phrase chosen in place of another word or phrase in order to communicate an attitude or meaning without stating it explicitly
[…]
4 : genetic code
5 : instructions for a computer (as within a piece of software) writing code for a new app

The term code as related to software started life as a metaphor and has become a definitional term for software source. With the rise of assemblers and compilers, the structure and appearance of source and object code grew farther and farther apart. The source was seen as a code in the sense of definition 3b: a system of human-readable symbols (letters and numbers) used to represent a machine-readable form of a program. Merriam-Webster recognized this and added the definition to the list…at the end.

Where software goes, bugs follow. We commonly accept the term bug to mean some kind of flaw in software. Debates around the term tend to focus on what kind of flaw, or where the flaw came from, or how large the effort to fix it may be. But there’s no debate that a “bug” is a “flaw.”

But why “bug?” Popular history credits Grace Hopper with coining the word “bug” after she found a moth had fallen in love with a relay in one of the early electronic computers.

That isn’t the origin of the term. It’s one of those myths that tend to accumulate around well-known people, like moths to a flame (that’s a simile). There was a moth, however. Literally.

The moth ended its life on September 9, 1947, in a Mark II computer. Hopper was the leader of the team, but it wasn’t she who found the moth. Bill Burke, one of the computer’s operators at the time, taped the moth into the log book with the comment, “First actual case of bug being found.” Here’s a photo from Wikipedia:

Notice the way Burke phrased the comment: He isn’t coining a new term, he’s making reference to a term that was already in use. In fact, if you read the history, you’ll find others who used the term in writing (even Ada Lovelace, referring to Charles Babbage’s Analytical Engine in 1843, and Thomas Edison, referring to the light bulb in 1878) were clearly using a term that was already well-known at the time. References go back in time all the way to the Middle English bugge, which persists in words like bugbear and expressions like bug-a-boo. And even then, the word had to have come from somewhere. It predates Middle English. It’s use in the software field is relatively recent, and yet quite clear.

A scrum is part of a game called Rugby. The game is well known in many countries and unknown in many more. In the context of the product development framework called Scrum, the daily scrum is an event when team members touch base (metaphor: there are no bases in Scrum) to ensure everyone understands what’s happening on their project, and can ask for and offer help with issues that are impeding progress. But team members do not literally cluster together in the manner of a scrum in Rugby.

Scrum, as it relates to software development, started life as a metaphor. It became the name for a product development framework based on a cross-functional team that hands off work to whomever is in the best position to get it done at the moment, in the way a Rugby team moves the ball down the field. The metaphor comes from a 1986 article in the Harvard Business Review entitled, The New New Product Development Game, by Hirotaka Takeuchi and Ikujiro Nonaka.

The article was influential in the development of the product development framework named Scrum, created in the early 1990s by Ken Schwaber, Jeff Sutherland, and others. Today, it’s isn’t “merely” a metaphor; it has become the name of a real Thing – the Scrum framework. But most of the metaphors we toss around (metaphor: you can’t literally toss a word) don’t rise to that level.

Metaphors People May Have Forgotten are Not Defining Terms

Not all Pinocchios become real boys. That’s a metaphor that refers to metaphors; a sort of meta-metaphor. It’s an appropriate way to start this section, as many people in the software field believe their Pinocchios are real. That belief can lead them to focus on the wrong things, or on things that aren’t Things at all.

We use buzzwords so frequently that we can easily forget which ones are definitional terms and which are only metaphors. Fortunately, there’s a hint: If a buzzword seems to generate a lot of debate or argument about its meaning, it’s very possible the slipperyness of the word (metaphor: words are not literally slippery) is due to the fact it’s a metaphor for something else. Metaphors are subject to re-interpretation, as they aren’t used in their literal sense. That’s perfectly okay; a metaphor doesn’t have a right to a clear meaning (that’s a metaphor: words can’t have legal rights).

When you use them, do you recall consciously that they are metaphors, and not real Things? Do you fall into the trap of trying to perfect or extend the metaphor at the cost of paying attention to the Thing it represents? Metaphors like these, for instance:

• engineering
• craftsmanship
• debt
• legacy
• agile
• extreme
• sprint
• velocity
• momentum, inertia
• self-organization
• self-assembly

What sort of Thing is software development? Is it engineering? Is it craft? Is it construction? Is it manufacturing? Is it science? Is it literature? Is it something else entirely? Is it, maybe, sort of like those things some of the time, but not exactly any of them or all of them? People debate this because they’re debating the meaning of a metaphor, and everyone can be “right” at the same time because a metaphor is not the Thing it represents.

We like to use the term “technical debt.” I wonder how many software development practitioners are aware the metaphor was created by Ward Cunningham in the context of explaining the value of incremental delivery to a client in the financial industry. The ways in which people use that metaphor today range far and wide from its original intent, and often lead people to waste time focusing on the wrong things…because it isn’t a Thing at all, it’s only a metaphor. People have invested time and effort to perfect and extend the metaphor, rather than investing that time and effort in understanding its intent.

The word legacy has come to represent something bad about the design of software that was written sometime before we showed up. But that isn’t the meaning of the English word, legacy. It’s only a metaphor. The legacy of an existing software system may be, in large part, the decades of profitable business operations it enabled for its owners, and in much smaller part, some aspect of software design that contemporary software developers find questionable in hindsight. But the metaphor carries a negative connotation among software professionals, and focusing on the metaphor instead of on the Thing causes developers to assume that existing code is generally poorly-designed, whether that is true or not.

Agile is a term coined by a group of software professionals who were trying to understand the common elements of successful software delivery and describe those elements in a handful of succinct statements. The word evokes imagery of lithe, flexible things and people, like fauns and ballerinas. It also coincides with the name of a certain type of trained dog competition. The metaphor seeks to capture a few key ideas, like the ability to respond to change gracefully, and the emphasis on getting things done as opposed to just writing down the intention to get them done. It has come to be used to describe all manner of formal methods and specific team practices, and is often applied in a way contrary to the intent of the original group. Why? People focus on the metaphor instead of the Thing.

A timely example appeared on Twitter while I was working on this post. This photo was posted along with the comment, “When you spot #Agile at work outside of software development. Still under construction while leasing units? #iterative #scrum”.

What are the chances the property owners or construction workers are thinking consciously about “agile” or intentionally, purposely using the Scrum product development framework? The scene has nothing to do with “agile,” “iterative,” or “Scrum.” This is an example of extending a metaphor beyond its intended meaning. It isn’t an unusual situation at all. Nearly all multi-family structures are built in such a way that the first completed units can be occupied before the last units have been finished.

Extreme Programming (XP) was described early on as doing the things that “work” and then turning the knobs up to 10 (metaphor: There are no knobs on software development processes). But it really describes an effective way of building and delivering software solutions; it isn’t actually “extreme.” It includes practices that have been shown to be useful and practical for building software. People focus on the word “extreme,” and assume the good practices aren’t for everyone. They must be difficult, strenuous, arcane, and stressful. Otherwise, why would they be called “extreme?”

From the Scrum framework, we have the metaphor of a sprint to represent a time-boxed development iteration within which a team is expected to deliver a potentially-shippable solution increment, or otherwise to make quantifiable progress toward their goals. It is not literally a “sprint” as the word is used in plain English. In a real sprint, the runner pushes absolutely as hard as possible to run as fast as possible, with no thought to what will happen after he or she crosses the finish line. If software teams operated that way, they would burn out very quickly.

We’ve already mentioned velocity, a concept borrowed from the physical sciences that only vaguely means anything at all in the context of software development. There is some sense of progress at some rate in a defined direction (toward the project goals), but it really isn’t the same thing as velocity in physics. Not even close.

The terms momentum and inertia, borrowed from the physical sciences as was velocity, are also widely abused terms. They are often used as metaphors for a perceived trend in performance. “That team has good momentum; if they can maintain their inertia, they can deliver more Story Points in the next Sprint.” Nonsense.

One of the most popular terms in the “agile” community is self-organization. It is mentioned in the Principles section of the Agile Manifesto:

The best architectures, requirements, and designs emerge from self-organizing teams.

This is a buzzword that tends to generate a lot of debate. Remember, that’s a hint that it may be a metaphor that people are trying to extend beyond its original meaning.

According to the Business Dictionary, self-organization means:

Ability of a system to spontaneously arrange its components or elements in a purposeful (non-random) manner, under appropriate conditions but without the help of an external agency. It is as if the system knows how to ‘do its own thing.’ Many natural systems such as cells, chemical compounds, galaxies, organisms and planets show this property.

According to Scrum, the self-organizing team is guided by an external agency – the ScrumMaster. Therefore, even when “self-organization” happens as intended in Scrum, it isn’t self-organization.

Joseph Pelrine coined the term self-assembly as a metaphor for teams that aren’t self-organizing in a meaningful way. Team members come together and do work, but they don’t become a cohesive team or collaboratively improve their practices. They are just a group of people whom management has assigned to the same project, probably temporarily.

The distinction Pelrine draws between self-organization and self-assembly is largely artificial. He wants to distinguish between “true” teams and work groups that are merely labeled as “teams.” It is meaningful and useful to draw that distinction, but the actual meanings of the terms self-organization and self-assembly are virtually the same.

Here’s a description of molecular self-assembly from a National Institutes of Health article:

Self-assembly is a process in which components, either separate or linked, spontaneously form ordered aggregates. Self-assembly can occur with components having sizes from the molecular to the macroscopic, provided that appropriate conditions are met. Although much of the work in self-assembly has focused on molecular components, many of the most interesting applications of self-assembling processes can be found at larger sizes (nanometers to micrometers).

When we use the term self-assembly in reference to software development teams, clearly we cannot possibly mean it in its literal sense.

What New Metaphors Have Emerged?

Emerging technologies such as “cloud” and “microservices” and “internet of things” have given rise to new metaphors. Here are five:

• cloud
• edge
• fog
• mist
• transduction

The first four are weather-based metaphors. Michael J. Martin has an excellent write-up on LinkedIn explaining how the weather phenomena of cloud, fog, and mist relate to software concepts. Edge is not dissimilar.

The metaphors fog and mist pertain mainly to the Internet of Things, or IoT. They describe architectures in which computing power is decentralized to varying degrees to enable programmable “things” to operate automously and to interact with one another without the overhead of routing all messages through a central hub. The metaphors imply different things about architectural patterns used for such solutions, including centralized, distributed, and federated.

Devices out on the edge of the network must exchange data with real-world objects. Otherwise, they wouldn’t be of much use. The term transduction has been borrowed from the field of biology to describe this data exchange. Transduction actually refers to the transfer of foreign DNA into a cell by a virus or viral vector. Outside a Terminator-style vision of the future, we clearly don’t mean to say exactly that when we discuss transduction in the software field.

Some metaphors don’t live very long. I gratefully observe that the “Foo-as-a-Service” pattern appears to have run its course. What used to be called Function-as-a-Service is now called “serverless.” Even if it isn’t literally serverless, it’s a more palatable metaphor in my opinion (metaphor: we don’t eat metaphors, and even if we did they would have no flavor, except perhaps metaphorically).

How Much Weight Should We Give metaphors?

The answer may amount to more than simply keeping in mind the known value of metaphor in human communication, and the known limitations and potential pitfalls of clinging too closely to our favorite metaphors. Metaphor can provide a useful shorthand for concepts that would otherwise take up too many words and too much time.

Take, for instance, the idea of digital transformation. Does the phrase have any real meaning? The word digital has to do with devices that operate on the basis of the binary numbering system. All electronic computers in mainstream use today are digital devices. What’s so special about “digital,” then?

It turns out in the context of contemporary marketing language, “digital” doesn’t mean digital. It’s a metaphor for “new stuff” like data anlytics and machine learning.

And what do we mean by “transformation?” Is it just a Sunday word for “change” or the title of the discarded first draft of Franz Kafka’s The Metamorphosis?

It turns out in the context of contemporary marketing language, “transformation” means changing your organization in profound ways so that it becomes capable of recognizing and taking advantage of emerging technologies. The idea stands in contrast to the more-common situation in large organizations, whereby leaders focus on minimizing the cost of keeping the lights on rather than actively looking for creative ways to exploit emerging technologies.

As a metaphor, digital transformation packs a lot of meaning into a couple of words. Even when we know full well what the words “digital” and “transformation” really mean, we can use the phrase digital transformation in a meaningful way to facilitate communication.

Conclusions

In summary:

• A metaphor is a word or phrase that stands in for a real Thing (conceptual or physical)
• Metaphors can help us begin to understand unfamiliar concepts by relating them to more-familiar ones
• No metaphor is the complete definition of the Thing it references
• If we forget where metaphor leaves off and reality begins, we risk focusing on the wrong things
• Many of the words we use in the software field started out as metaphors, and most of them are still subject to a lot of manipulation and re-interpretation
• Using metaphors intentionally for the purpose of clear communication can be a Good Thing