Software development is full of mixed metaphors. We talk about “engineering” and “architecture” a lot. Yet what we do has very little in common with the engineering and architecture we see in other industries (for example, bridge or house building).

In the last couple of decades, craftsmanship has taken hold as a metaphor for software development, complete with proposals for how developers should act as apprentices and journeymen on their path to software development mastery.

But software developers don’t have a trade guild in the sense that existed in medival Europe, which enabled and necesitated the apprentice/journeyman progression.

I’ve also seen attempts at using gardening as a metaphor for software development, because code and projects tend to grow in seemingly organic ways that can be influenced, but never completely controlled.

The trouble is that none of these metaphors really seems to capture the essence of the joys and frustrations of software development, software delivery, and software maintenance.

So what is the right metaphor?

Well, there isn’t one.

Or they’re all good.

Huh?

There’s no literally accurate metaphor for software development for the simple reason that metaphors are never literally accurate. By definition:

metaphor noun
a figure of speech in which a word or phrase is applied to an object or action to which it is not literally applicable.

But metaphors still serve a purpose. That purpose, though, is often hard for those of us trained in logic and exactitude to appreciate.

The whole purpose of a metaphor is to communicate. We use a metaphor as a stand-in for a complex or not-yet-understood reality, so that we can communicate about that reality in ways that the hearer can more easily grasp.

In this sense, talking about “engineering” is perfect, if the aspect of software development you’re attempting to communicate about relates to the design of a bridge in some way.

It’s probably less useful if you’re trying to describe the organic, fluid growth of a software project.

So there’s no need to banish one metaphor in favor of another (as the Software Craftsmanship Movement seems to have tried to do with the “engineering” metaphor). But we should be mindful about using metaphors that help us communicate in the moment. And if we can get our point across more effectively by mixing otherwise incompatible metaphors, why not?

Maybe we need more metaphors, not fewer.