Metaphors are everywhere. When we express ourselves we can’t help but using them. We mostly do it unconsciously. Metaphors are the mind-friendly way to convey new concepts that don’t have yet a name in our vocabulary. As a matter of facts, every word we currently use in our daily communication was once a vivid, explicit metaphor that became sedimented and forgotten as such over the centuries.
If we now think about the last 50 years or so and the relatively fresh computer science revolution we’re living in, we can realize that in order to express related concepts we can’t help but resort to an ocean of newly created metaphors: cloud, garbage collection, bug, stream, pipe; I could go on forever.
This is simply how our mind functions, and it works more or less like this: “uh oh, look, a new abstract concept. What’s the most similar labeled experience that I have in my memory? I’ll name this new concept after that.”
Let’s take the garbage collection example. When John McCarthy was working on improving Lisp, in 1959, he came up with a new mechanism to simplify memory management by automatically locate all data objects which were not anymore accessible by the runtime and free their related memory portion. I’m pretty sure that in that exact moment something happened in McCarthy’s mind: he extracted the emergent characteristics of the abstract concept he was trying to give name to (process, repetitive, delegated, free a resource, removal, uselessness) and he associated it to the most similar labeled experience he had in his mind: garbage collection.
Let’s now move to software development. Obviously enough, this is one of the most metaphor-rich branch of computer science. Just think about design patterns. The vast majority of them is named after a metaphor source completely unrelated to computer science: Factory, Builder, Singleton, Bridge, Decorator, Facade, Proxy, Memento, Visitor, etc.
But how metaphors affect the way we design software? Why is it important to be aware of this mental process? And which pitfalls should we be careful about and try to avoid?
To answer those questions, we need to understand the concept of metaphor framing.
Back to the McCarthy example, when he came up with the name garbage collection, he associated only few characteristics of the metaphor source with the target, leaving out the ones that didn’t fit its purpose: noisy truck, bad smell, separation and recycling, plastic or aluminium can.
The same happens when we say to our beloved one “you are the sunshine of my life”. We definitely don’t mean “you are an ultraviolet radiation of vast proportions that could cause me sunburn, premature ageing, eye damage and skin cancer”…don’t we? So we ignore and discard those characteristics and focus only on warmth, brightness and (serotonin induced) happiness. This is what metaphor framing is about.
When we design software, every time that we use a metaphorical abstraction we are also applying metaphor framing to the source. It’s the frame content, not the full source that we use to shape the design of our software. The bad news is that our mind do that silently and unconsciously. This could lead to unpleasant situations where we start with a metaphor (let’s say, an Engine) and we follow the design that the metaphor seductively suggests us (it’s an Engine, so it must be started and turned off; we have only one Engine; its components should be named Gears; the Gears need synchronization between each other). All of sudden, our software, our solution space starts speaking a language very different from the one of the problem space we were meant to model. This is a dysfunction in software design that I like to call kidnapping by a metaphor: our mind simply went too far, applying a very broad frame that is not useful anymore for the purpose of defining an effective domain model. One that is essential and fills the gap between the problem space and the solution space. One that speaks the domain language and is communicative to everyone in the room.
Speaking about it, we always need to remember that a metaphor is an act of communication, and as such it can’t fulfill its purpose when taken too far, when the so called ligamen, namely the link between the source and the target, is too threadbare, too distant for the recipients to solve the cognitive dissonance the metaphor is challenging their minds with. Even if it makes sense for us as the authors, people not used to our exact style of metaphor framing, people with different enough experience from ours simply won’t get it.
I think most of us felt that sensation at least once in their programming life: “what the heck does this code actually mean?!”. I once had the delight of debugging a piece of code that involved classes named after Lego blocks; pity it was related to the generation of financial transactions. This is what I’m talking about.
So, what should we do in order to avoid being kidnapped by metaphors and ensure that everyone is on the same page while designing and developing software?
First of all, we should always be aware of the metaphorical process in our minds. This is an incredible feature we can leverage while designing software, but we need to keep it under control or it will unconsciously control us. What we need is constant awareness.
We should make sure that everyone understands the chosen metaphor frame. If other people find the metaphor weird, chances are that the frame we chose is too stretched to fit the problem. Repeatedly ask for feedback.
We should also make sure that the metaphors open new modeling opportunities without interfering with the communication among developers and more in general with everyone involved in the development process. Give priority to clarity and effectiveness.
In this post, I barely scratched the surface of the metaphorical mechanisms, stressing its effects on collaborative software design. Don’t get me wrong, metaphors are one of the greatest gift that we as human beings have to give birth and foster our creative process, but we need to be aware of the mechanisms that govern our mind to control it and align it to our current purpose. In terms of neuropsychological and communication dynamics there is so much more going on behind the scenes and I warmly invite you to find out more, but for now let’s stop here; we risk to go down a very, very deep rabbit hole (<- metaphor again, you see?).