Why Use Analogies in Software Teams?

2021-08-15

Software developers and technologists are often afforded the time to learn niche and complex material through study and deep interaction. Many times, it is simply part of the job to wrestle with obtuse concepts and systems in the process of delivering something of value to the company or organization. This learning can come from deliberate study or merely from doing regular work duties, such as creating or maintaining a computer program or system.

Colleagues in other roles, like managers, directors, and analysts, might not be provided the same opportunities to gain the specific knowledge developers pick up as part of the job. As a result, developers often become the natural subject matter experts on the things they work on.

As the technical experts, software developers are counted on to provide insight into the behaviour and effects of software systems. This is often not an easy task. Understanding how an application or a system works internally may require specialized knowledge that non-developers cannot be expected to pick up within a short conversation or meeting.

The question then is: How can developers provide stakeholders just enough information to minimize complexity and yet allow them to understand important details and make informed decisions?

Fortunately, as a matter of necessity, any good programmer is already intimately familiar with managing complexity. A pervasive Computer Science concept that comes to mind is abstraction, which involves “filtering out — essentially, ignoring — the characteristics that we don’t need in order to concentrate on those that we do.” (BBC).

In programming, constructs like functions, classes, libraries, and APIs are all created as a means to reduce complexity while allowing informed interaction. In conversation and writing, analogies take a similar role. Analogies convey the rough shape of an idea by comparing it to something already familiar to the recipient. The good use of analogy is a tool developers can use to communicate the important bits of information to stakeholders in a way that is easy to understand and reason about.

Of course, all analogies break down — and so they are not meant to take the place of technical descriptions or documentation. But in situations where time and energy is constrained such that people cannot be expected to pour swathes of time into reading documentation, good analogies are often sufficient.