3 Metaphors for Computer Code

Code is intangible.

So, to make it more understandable, we use metaphors from the real world. Here are three that I find particularly useful:

Code as Property

As we know, a house requires maintenance. Periodically, you have to repaint the facade, redo the roof, bring it up to code (electricity, heating…), and inside, take care of the walls, touch up the plaster here and there. An asset needs to be maintained; otherwise, it deteriorates and loses its value. You can’t imagine how much it costs to maintain a mansion 💎

Code is the same: periodically, you have to update dependencies to address security vulnerabilities and fix bugs (because even with the best intentions in the world and the greatest expertise, there will be some). And as a preventive measure, perform refactoring to allow the code to evolve more easily. Or even switch to newer technologies to stay in step with the skills available on the market.

This metaphor works quite well because it even incorporates changes: we add features just as we’d add a sunroom or another story to a house. We pivot (as a company, and thus as a product) just as we’d change the building’s purpose, shifting from commercial use to residential use.

And if, worn out by the struggle, we let up on our efforts, that’s the beginning of the end: see the broken-window theory.

Code, much like the human body

The cells of the human body are born and die. Over the course of a decade, nearly all the cells in an organism will have been replaced. And yet, our identity endures.

Well, this is probably a deeper philosophical question: my Social Security number remains the same, but am I the same person I was 20 years ago? (*) Am I a Social Security number? 😱

In any case, this sheds light on how to understand code: refactoring, or even technology shifts, means that an application’s code can change entirely without the service ever being interrupted. Personally, I think that’s really beautiful.

We add features just as we build physical strength or acquire new skills. We fix a bug just as we dress a wound. After all, don’t we talk about the “application lifecycle”?

The metaphor works quite well: a computer program is a set of modules that work together, just as the human body is made up of organs that function in harmony, a harmony that never ceases to amaze us.

The codebase… the equivalent of your kitchen?

Although perhaps less common, this last metaphor is nevertheless illuminating in several ways.

Cooking, like software development, is a craft, if not an art. We talk about “software craftsmanship” to refer to certain values: practice, learning, passing on knowledge, and, implicitly, a certain humility. Pride in a job well done: we come back to that time and time again.

This involves things that may seem trivial: just as a cook cleans their countertop and sharpens their knives, a developer closes the 38 tabs in their IDE and adds an ESLint rule.

Would you try a dish made by a cook who hasn’t done the dishes in a month? I’ll let you draw the parallel for software development.

Beyond that, the kitchen is a highly optimized space: the most commonly used utensils and condiments are within easy reach, while the ice cream maker sits tucked away in the back of a cabinet (well, that depends on your specialty and the season).

And that’s a basic principle of UX: “make it obvious/simple/possible.” This prioritization of actions is the foundation of the apps we love, because beyond just making actions feasible, it makes them enjoyable.

(*) In other words, we are entities in the sense of Domain-Driven Design.