Metaphors in Software Development: Understanding a Complex Universe

Metaphors are among the most powerful communication tools available to us as human beings and software engineers. Indeed, metaphors enable us to apply intuition developed in a more familiar domain to a complex one. This way of thinking is particularly useful when approaching abstract domains.

So it's not surprising that software engineering is a field where metaphors and metaphorical language are commonplace. We talk about debts, factories, crashes, bugs, worms... All these comparisons help us to better explain software development. So, whether or not you're familiar with all the technical language involved in software engineering, I invite you to discover in this blog post some of the most common metaphors used to explain the complex world of development.

Why are metaphors useful?

When we’re facing difficult and complex problems, solving the problem can be just as difficult as simply communicating the context in a well-posed way. Metaphor helps to :

• Conceptualizing problems
• Understanding things better
• Solve problems
• Communicate with stakeholders

Some examples of metaphors

The use of metaphors in software development is not new. Some of them become more well-known and widespread in the collective imagination when they reach a large group of developers. In particular, there are four that have proven their worth in democratizing software development and bringing greater understanding to stakeholders. Software development is like:

1. Building a house
2. Plant a garden
3. Learn crafts
4. Manage finances

Developing software like building a house

A house without a foundation is simply not possible: it's the first non-negotiable step. Imagine your contractor telling you, "Doing the foundation will take an extra three weeks, because we're short on cement... But since we promised you the house by date X, we're going to take a shortcut and do the foundation in wood." What would you say?

So why would you be prepared to make such sacrifices when it comes to building your software product? It often happens in software development that we want to get straight to the keyboard, forget about testing and neglect to do a minimum of analysis: we're prepared to sacrifice our foundations in order to meet our deadlines. As software engineers, our role is to defend the foundations and make the customer understand the impact of changing our best practices in favor of a deadline based on estimates (I repeat, estimates!) in an evolving context. If the context changes (and it will!), or we discover unforeseen blocking factors, we absolutely must revise the game plan or push back the delivery date. The last thing you want to do is cut back on good practices and quality.

Developers are often seen as "coders": people who need to be at their keyboards typing code to be profitable. But as in construction, we need to take the time to analyze things, to sharpen our tools, to think of alternative solutions that might be cheaper and less complex, and to make sure that each of our actions will bring the best value for money.

However, this metaphor does not take into account the agility with which software development must operate. In fact, software development may begin before the company's needs have materialized, and it is therefore possible for these needs to change after the building has begun construction, or even after a dozen floors have been built. This is probably why the metaphor has evolved into a more iterative construction site: gardening.

Developing software like planting a garden

A computer system is like a garden: it's alive. We don't know how fast things will go, and there are many imponderables. However, we do know the favorable conditions that can lead to the desired result.

For example, if temperatures are normal, the soil is rich and I take good care of my cuttings, I can predict that my plant will probably reach six inches in June. But that's still an approximation! And the plan(t) may change along the way. In gardening, we expect a lot of less orderly things to happen, such as a plant outgrowing, dying or requiring constant maintenance.

In software development, it's the same thing. You start with an idea of the desired result, you put everything in place to achieve it, but you adapt to the new needs that emerge with each new delivery.

«Gardening is planting, pruning, and killing weeds, in software development, it’s like coding, detecting code smells, preventing code rot, refactoring.»
— Park Sehun

Developing software like learning a craft

In recent years, I've seen an evolution towards the notion of "craftsmanship", with mentors to share best practices.

To ensure the industry's longevity, junior professionals need to be coached to the next level, so that knowledge can spread.

Software development has become much more democratic in recent years, but not all developers have the same rigor as the first computer scientists, so the quality level of developers is becoming diluted. Since the number of developers doubles every five years, half of them have less than five years' experience. So it's important to have a good mentor to help you acquire a solid grounding in the profession. Without a notion of "craftsmanship", where old hands mentor new ones, there's a risk of losing control, and considering that all our lives depend on IT today, mentoring is essential.

Developing software like managing finances

The metaphor of technical debt, coined by Ward Cunningham, is a financial analogy. Borrowing money is a quick way to obtain new funds and, indirectly, other resources. As most of us know, when you borrow money, you have to pay it back later. You also have to be prepared to pay an interest rate. If you keep borrowing money, you end up paying an interest rate so high you can't afford it.

If you launch software quickly and ruthlessly, taking shortcuts again and again, you end up in a situation where the code becomes impossible to use and maintain, unless you clean it up. The fast approach is analogous to borrowing money: you now have a substantial technical debt. With such a debt on our hands, we'll be terrified of adding new features to the code (since we don't really understand it), and we'll most likely have to spend a lot of time fixing defects (aka bugs) to avoid disaster (aka bankruptcy).

The analogy of refunding in software development is the refactoring process. By constantly monitoring for signs of degradation ("smells") and constantly cleaning up the code, regular refunds are made in order to understand the code and keep it malleable for the future.

The dark side of the force

While metaphors have many advantages and help us to illustrate abstract concepts by relating them to the concrete, there are certain shortcomings when using comparison. Metaphors are excellent communication tools, as long as we are aware of their limitations and take them with a grain of salt.

Remember to observe the link put forward by the author, without using metaphors for other purposes. There's no point in appropriating metaphors in a new context that goes beyond the initial need for comparison, where we run the risk of making the metaphor speak as we see fit. It's very easy to draw false equivalences between software engineering and what we already know...

Moreover, metaphors are themselves limited in certain circumstances, for example if the mapping is inappropriate or inadequate, or if we adhere too rigidly to the metaphor, so that it limits reflection.

« Metaphor and analogy can be helpful, or they can be misleading. It all depends on whether the similarities the metaphor captures are significant or superficial. »
— Herbert Simon, The Architecture of Complexity, 1962

As consultants, our job is to help customers understand our value, and this sometimes involves analogy, but we need to eliminate discrepancies and ensure that comparisons are fair and accurate to really communicate value in a familiar way.

Ressources pour aller plus loin :

• Code That Fits in Your Head (chapter 1), a book about writing code at a sustainable pace and mastering the complexity that causes too many software projects to spiral out of control.
• The Software Craftsman (chapter 3), which explains how to adopt this software craftsman mindset to achieve unprecedented levels of technical excellence and customer satisfaction.
• Mikado method (Appendix A), describing a pragmatic, simple and empirical method for planning and implementing technical improvements to an existing software system.
• Modern Software Engineering (Chapters 1 and 2), in which David Farley highlights the sustainable principles at the heart of effective software development.
• Code Complete, Chapter 2 is entirely devoted to metaphors to enrich our understanding of software development.