Metaphors are a part of our everyday lives as software professionals. We use them to describe concepts, features and even complete systems to each other on a daily basis, but what are they exactly?
Kim Halskov Madsen wrote an article in 1994 called “A Guide to Metaphorical Design” and I think this is worth a read for everyone interested in improving their ability to describe concepts that may be hard to grasp e.g features to customers, a complete system to your boss, or just a newly build class to a fellow colleague.
One of my personal favorite metaphors isĀ The Chicken and the Pig and how these two animals can describe commitment in a project.

How to use metaphors

The article explains how metaphors should be generated, evaluated, and developed.
A metaphor should, if possible, build on already existing metaphors e.g. something already existing in the problem domain.
If a predecessor artifact is already described this can be used as a metaphor e.g. files in file cabinets can be used to describe file systems on computers.
Rich structures are important for metaphors because general or abstract metaphors can become a problem e.g. a link can mean a lot of things, a path from somewhere to another, something describing a relationship between a source and a destination etc.
One should always evaluate the applicability of the structure chosen for a metaphor: does it really cover all the important aspects? Or can it be seen as misleading?
This also relates to the fact that one should use a metaphor that is suitable to the audience. I reckon that this is the reason why business and software people often talk past each other. They do not communicate in a language which they both understand.
E.g. a pointer metaphor is fully understood amongst software developers, but business personnel can have a hard time figuring out what a pointer is and what it represents.
Metaphors should be chosen with well-understood literal meanings, as the key aspect of metaphors is explaining something in terms of something else.
Metaphors are used for seeing something in a different light; from another perspective. Therefore, metaphors should be chosen with a conceptual distance between the source and the metaphorical meaning. E.g. a credit card can be metaphorically expressed as an electronic wallet or pocket.
It is important to have one or more bridging concepts contained inside the metaphor e.g. how the pig and the chicken commit to making brunch! In this example project, commitment and cooking form the bridge.
Elaborate assumptions – it is important to explicitly express what the metaphor hides and what it highlights.
Metaphors often use triggering concepts, e.g. “to meet the customer in a new way”, and these are necessary to elaborate upon.
Identifying the unused parts of a metaphor, e.g. aspects, features, and properties, in the source domain, can be used for gaining a more profound understand of the target domain.
Talking about the target domain as if it was the source domain, can be used for understanding how the target and source domain is intertwined.
Metaphors are helped by psychical structures in everyday experiences and can be used for describing abstract concepts in terms of concrete and familiar objects.

Metaphors can even be used for providing detailed, specific design options, and as a basis for justifying design decisions.
They can help people see something as something else and describe a model of the system which they can familiarize with.
Metaphors can shift the focus of attention and create a problem setting – they can provide a novel view of reality.

I hope this can help you understand how to use metaphors as the great tools they are – both for communicating with others, but perhaps even more with understanding problems at hand in a new light.