by Eric Evans
February 4, 2004

We can’t quite think about a completely new thing, so we make analogies to activities that we think we understand better. Software, being only half a century old, has been laden with the baggage of many established professions. Metaphorical thinking is so powerful that an inapt or misapplied analogy can be devastating.

Software development is like manufacturing.

The century before last, some people figured out a way to crank out endless copies of identical items, and the world became much wealthier. So let’s apply the same techniques to software “production”, the thinking goes, and we’ll enter a new era of abundance.

Software development is something like the R&D of new products, but it is nothing like production. Making copies is a trivially easy part of software development. Applying this manufacturing metaphor has done terrible harm. It suggests that much programming work can be carried out by people without deep technical skills or creativity, and so project after project staffs the wrong people. It suggests that results can be (and should be) predictable, and so project after project institutes processes that make upside surprises impossible, while giving only the illusion of limiting downside surprises. Is it any wonder, then, that the workplace ends up about as stimulating as a factory floor?

Of course, before there were factories, crafts-people created useful objects, which were relatively costly and of variable quality. If there had existed the ability to effortlessly replicate objects created by the world’s best crafts-people, would we ever have had factories? We don’t need software factories.

John Brewer, for one, is fond of pointing out that we don’t even apply well the lessons this metaphor should carry. The manufacturing principles usually employed leave out most innovations of the twentieth century such as devolving control to small teams on the factory floor. There is, no doubt, something to be learned from manufacturing technique, but it not an apt metaphor for the overall software development process. And the truth is, we in the software business don’t know much about manufacture.

Software development is like architecture.

I was once persuaded by this metaphor, but became skeptical as I observed its results:

• Smart, experienced people become incompetent through loss of hands-on practice.
• Tasks that call for massive feedback divided among groups that communicate bureaucratically.
• The natural emergence of dynamic, creative design work squelched by remote idealists.
• A programmer underclass established.

The architecture metaphor is seductive and seems, at first, more apt than manufacturing. Architecture is a creative design process that involves satisfying a customer within technical constraints. Sounds like software. Then carpenters and bricklayers come and build the house. Not so much like software.

And plumbers and electricians. For some reason, the analogs to the plumbers and electricians get all the glory in the software projects. Once again we aren’t even employing the metaphor very well, since these services, while well-paid skilled labor, are not the focus of the effort of building a house. The software analogs of plumbing and wiring are what most developers want to work on, and what fills out their resumes. Of course, it is better than being a software bricklayer.

The truth is, I don’t know all that much about architecture, and neither do most other software professionals. I’m frankly not sure what the flaw in this analogy is. I won’t go to much effort to analyze it because in this case the empirical evidence of harm convinces me that this metaphor is best abandoned. An objective observer of most of these architecture-oriented projects might conclude that software development is like working at the DMV.

My turn.

Shall I propose yet another metaphor to replace these failed ones? How about experimental science? In model-driven design we formulate a hypothesis (model), test it with use cases and early software versions, reject or refine, and repeat with a new model. Or how about painting? I once read a beautiful metaphor contrasting watercolor (where the artist has to get it right the first time) with painting in oil (where the artist can incrementally refine the image).

Or literature. The one thing I’ve done in my life that felt anything like software development was to write a book. In domain-driven design, the development of a powerful language is central to the project’s efforts. In which other activities is finding a good way to talk about things half the battle? Or how about a voyage of discovery, where we depart with goals and a destination in mind but are prepared to find and exploit the unexpected. I think there is some merit to these metaphors. But, no. I will not get swept up in these metaphors.

Let software be software.

The argument is not against metaphorical thinking. The point is that it is too powerful a tool to be used indiscriminately, and we are not using it well. You wouldn’t cut bread with an acetylene torch. You wouldn’t cut steel with a chainsaw. The typical problems are (1) applying metaphors too broadly, (2) applying them too literally, (3) drawing on domains we know little about to inform our own specialty, and, above all, (4) applying metaphors too uncritically.

We’ve been using the same tired metaphors for decades and they are not serving us well. What there was to learn from them was absorbed long ago.

We can learn from other professions, but it is time to stop trying to shoehorn our activities into those forms. And most of us know a lot more about software than about manufacture or architecture. The fields we draw these metaphors from don’t have metaphors to other fields, they are what they are.

I can imagine a neolithic farmer, 10,000 years ago, trying to explain what he was doing to a friendly hunter-gatherer. “Farming is like chipping flint,” he would begin…

We use metaphorical thinking best when we use it lightly and narrowly. I’ve heard Kent Beck talk about manufacturing in trying to explain Extreme Programming (XP), but he also uses a metaphor about gentle valley people versus savage mountain people who abandon their kids¹. XP is not based on a metaphor, unless it is down-hill mountain biking. Beck takes up these metaphors to make some point and then puts them down again².

Software development is what it is. Experience is teaching us which practices work and which don’t, which technologies help and which get in the way, and the consequences of different team organizations. Overstretching comparisons to fields we don’t know much about holds us back. Software is something new under the sun.

¹ page xviii in Extreme Programming Explained: Embrace Change

² The XP sytem metaphor practice is a whole different issue.

©2004, Eric Evans