Software Metaphors

Metaphors are very diffused in programming, trying to bridge the technical part of it with comprehension of real world objects. For example, think of technical debt: a financial metaphor saying that you can take shortcuts and pick up debt in your code, but you'll have to regularly pay interests in development time during maintenance.

Where do we think in metaphors?

Almost everywhere in software and in software development. The GUI you're probably using to read this article is based on a desktop with some folders on it; if you want to read it later, you'll create a bookmark on this page.

System metaphors like this one are one of the practices of XP and DDD: they facilitate the team's communication by borrowing an existing language and grounding into real objects what a AdapterFactoryImpl is.

Here are some system metaphors, at the application levels:

• the shopping cart in e-commerce mimics how a supermarket works, collecting products and quantities at different times and leaving checkout for the end for efficiency.
• The various app stores and web stores for purchase of mobile and desktop applications mimic the process of buying products off a shelf from a single store; in some cases, showing even fictitious boxes representing the installation packages, which are actually downloaded.

But metaphors also target the process of software development, and not only the final product. A software can be:

• designed by an architect and built like an house by the compiler.
• Grown like a crop.
• Found by navigating in a solution space, paying attention to our inertia.
• Composed from objects like a circuit.

And metaphors are not even constrained to our field: for decades elementary concepts of electrical engineering have been explained with the water metaphor substituting the flow of charges. In this metaphor, voltage is equated with height or pressure difference and current with water flow; components like capacitors are modelled as tanks which can be filled with water.

The comparisons comes up short in some cases, such as with the signs of charges which is not possible to model with a single molecule like water's. In general, all metaphors will model incorrectly some aspects of the original object.

Dangers

Let's say B is the real object our metaphor consist of, while A is the software under development that we thought as an instance of B. One of the dangers of overusing the metaphor is this logical fallacy:

A resembles B
B has property p
Ergo: A has property p
-- Bertrand Meyer, Object-oriented software construction

We cannot stricly deduct a property of the system from its metaphor. The C2 wiki however traces the process behind thinking in metaphors as:

B has property p

It is useful to pretend that A had a property structurally similar to p

Therefore it is useful to pretend that A resembles B

So we wouldn't often think that our desktop gathers dust like a physical desk; we instead equate it with the desk to explain that it has a limited, easily accessible space to place files and folders in; and that we should keep it in order if we want to continue to find things quickly. And we wouldn't request multiple carts from Amazon if we want to buy an high number of books.

The only language we have

In fact, even if metaphors could suggest inexistent properties of a system, we do not have a language different from metaphors if not for highly technical or abstract concepts, like a Turing machine or a CPU. Even cache was not a technical term originally, as pattern names such as Factory, Prototype and Adapter suggests a metaphor (respectively a building where things are constructed, the first instance of a product that other instances are copied from, and a power adapter for our devices).

In fact, the most technical terms are usually difficult to understand or thought as buzzwords. Middleware sounds like snake oil, while it is reasonable to talk about queues and messages to a distributed systems newcomer. In system programming, we create semaphors for mutual exclusion, not couples of wait() and signal() primitives.

Conclusion

Metaphors are part of our everyday language while talking about software and its development process: few people have the luxury of inventing new terms. Some metaphors are more deeply rooted in our knowledge and are clearly defined, like libraries or the Factory pattern; some application-specific ones should be explained to newcomers to avoid being misinterpreted. But all in all, borrowing the language of an existing system is natural and pushes us to think like people and not like a machine.