Analogies play an important role in our lives. They help us understand concepts and situations by mapping what we are already familiar with to the objects we want to be familiarised. We construct analogies all the time, often not even noticing their presence, as if the creation process is something rooted deep into our minds. However, some analogies are easier to create than others. Furthermore, there are analogies which fail to achieve their purpose, leading to multiple valid interpretations, or even to complete misunderstanding of the message.
Let’s start with two simple analogies, with straightforward answers:
Even for those who are not football fans, knowing that Cristiano Ronaldo and Lionel Messi are currently the main players for their respective teams is perfectly reasonable. As for the second analogy, Android and iOS currently dominate the mobile software industry and it is very likely that you have one of them running in your smartphone.
If we were talking to someone from a parallel universe where Google never joined the mobile industry, saying that "Android is to Google as iOS is to Apple" would trigger a series of mappings within that person’s mind, suggesting, for example, that Android is Google’s mobile Operating System, used in smartphones by many people, perhaps with a huge app store.
Now, what happens when we try to create the following analogy?
For some people, Washington, D.C. would be the immediate answer. After all, both cities are the capital of their respective countries. However, if you have ever been to London, you’ll know that the answer is not as simple as mapping two capital cities. London is not only the capital, but also the most populous city of the United Kingdom, the business centre, site of the British monarchy, as well as the main touristic city in the country. One can map London to New York, San Francisco or Washington, D.C, all for valid reasons, but none of them gives a complete representation of what London is to Great Britain.
Of course, the intention is not always to map every aspect of one object to another and, in fact, that would be impossible to achieve. In the previous example, If the intention was to explain the most populous city in the United States, saying that New York is to United States what London is to United Kingdom would probably suffice, but only if the targeted person was aware of that intention. Therefore, finding the proper analogy is essential when communicating an idea or situation to someone.
Analogies can also fail to achieve their goals like darts hitting the wrong target: they will map to wrong objects. The result can be the complete misinterpretation of the object. For example, telling someone that Starbucks is like McDonald’s could create an embarrassing situation where that person attempts to order a double cheeseburger at the Starbucks counter.
There are also cases in which improperly chosen analogies can cause serious negative impact to those involved. In an article published in the Harvard Business Review by Giovanni Gavetti and Jan W. Rivkin, the authors described the bad decisions made by executives at Enron as a consequence of using the wrong analogies:
Many factors contributed to Enron’s startling collapse, but headlong diversification based on loose analogies played an important role. After apparently achieving success in trading natural gas and electric power, Enron executives moved rapidly to enter or create markets for other goods ranging from coal, steel, and pulp and paper to weather derivatives and broadband telecom capacity.
But Enron’s executives failed to appreciate important, deeper differences between the markets for natural gas and bandwidth. The broadband market was based on unproven technology and was dominated by telecom companies that resented Enron’s encroachment. The underlying good—bandwidth—did not lend itself to the kinds of standard contracts that made efficient trading possible in gas and electricity.
As we can see in the case of Enron’s executives, concluding that the market for natural gas is like the market for bandwidth didn’t go very well.
A software project includes people from different areas and not every member is familiarised with concepts that are part of the software community. Imagine you are having a hard time trying to convince your Client or Project Manager that it is important for the project that the team spend some time refactoring the codebase (a familiar scenario for most of us). Saying things like "We need to refactor our code because it is getting more difficult to add new features." doesn’t sound convincing. It could even backfire to you with a reply like "Then why didn’t you write the correct code in the first time?".
A better way to explain the situation would be with the following analogy:
Just like a house needs frequent maintenance, otherwise even a small water leakage can become a nightmare over time, causing wall and painting damage, short-circuits in the electrical wiring, and so on, so does a codebase needs maintenance: otherwise the complexity can grow enough to cause damage to the release schedule, increase in the cost of adding new features and, consequently, generating loss of money.
Even when we are learning or teaching new concepts, analogies are useful. The most common way to explain Object Oriented Programming is by creating analogies with the real world:
An object in Object Oriented Programming is like a car. It has State (e.g. on/off; gear number and current speed) and Behaviours (e.g. change gear; reverse; accelerate). The internal parts of a car are like the internals of an object: they should not be exposed to the user and should only be operated through its interface (i.e. the wheels, pedals and shifter).
Many of us have also been through a common scenario: trying to explain what we do to a friend or relative who is not familiar with programming or the software industry in general. If you haven’t tried it yet, I would recommend you to, as it is a good exercise in improving our communication and you will certainly find yourself creating analogies. For instance, we are so accustomed to use words such as Array, String and Integer that we often forget they are rarely used in areas not related to Mathematics.
In an industry dominated by abstract concepts and technical terms, we can’t avoid the usage of analogies. While it is interesting to understand why some analogies are harder to create than others, it is important to choose those which will improve our communication and clarify the messages we share with our team.
Hofstadter, Douglas R. "Analogies and Roles in Human and Machine Thinking". Metamagical Themas: Questing for the Essence of Mind and Pattern. Basic Books, 1985.
Software es nuestra pasión.
Somos Software Craftspeople. Construimos software bien elaborado para nuestros clientes, ayudamos a los/as desarrolladores/as a mejorar en su oficio a través de la formación, la orientación y la tutoría. Ayudamos a las empresas a mejorar en la distribución de software.