Metaphor has a pernicious effect. It encourages people to take anecdotes as proof, effective rhetoric as useful advice and to accept only ideas which fit their preconceptions. Metaphors are better at conveying values than specific, practical advice. They can obscure the areas of ignorance and uncertainty where evidence should be collected and lead us to believe we understand things we don't.
Despite all that, I love metaphor. So far it is the most effective tool I've encountered for sharing values, the motivations for process and the assumptions we bring to discussions of how best to build software. Besides, I am the sort of person who sees parallels in everything I do. For me, writing software is like writing plays, post-modern lit crit, economics, psychology, art, poetry, baking, animal husbandry, gardening, physics, music and more. Some of these metaphors have usefully communicate to others (“coding reviews as writer's workshops”), others … not so much (“the computer as an economy”). Most often they are helpful going the other direction: I can describe coding to a poet by drawing analogies with their field, while most programmers probably wouldn't find those parallels useful because they are better versed in the language of software development than they are in the language of poetry.
Even though it may be where they are least needed, metaphors about code have always been employed when programmers talk to each other. Rather than invent a wholly new language, we compare our profession to everything from animation to farming. Sometimes these ideas feel more like thesis statements, a way to make otherwise context-less books flow and hold a reader's attention. Others are so widely embedded in our expectations that tracking down their origins is difficult.
Part of my background is in performance theory. It is the idea that people act in part to conform to or rebel against the stories they tell or hear about themselves. Psychology has more complete theories that describe individual manifestations of this, but I am interested, instead, in the interpersonal consequences of stories. We relate to other people based on what roles we see them play in our stories, and what role we see ourselves playing in theirs. If the senior person on my project describes themself as a “software architect” I will assume that my role as a programmer is different than if they describe themself as “technical lead”. They might actually perform the same tasks in either role, but I will assume that their expectations of my behavior are different, and so my behavior probably will be different whether or not I am conscious of it.
Metaphors are the stories programmers tell about ourselves. We are makers and builders, or we are scientists and engineers. We are crafters or servers. We are artists, assemblers, professionals, lovers of our profession. We are passionate seekers, humble students or skilled masters (or incompetent, frustrated, under-appreciated or under-performing geniuses). We are cowboys and ninjas and rockstars (oh, the assumptions in those...) Our stories about ourselves and our work change how we interact with each other, with our customers, with our code. I am never so intrigued by any specific badge as by the groups of people who choose to wear them.
For example, I believe that part of why “software is like building” became popular, rather than the more generic “software is like engineering” is because more programmers want to be like architects than engineers. We want to imagine ourselves as Frank Lloyd Wright, creating beautiful, useful, functional objects that people inhabit and own. As useful as electricity is, I admit that being Nikola Tesla is less appealing to me. “Architecture” as a metaphor lets us believe that we practical artists and artistic engineers. It makes us a part the tradition of architects, stretching back thousands of years and putting our not-yet-a-century of conversations to shame. Architects also have excellent PR, of course, and software isn't the only field to coopt the word. The job titles "Interior Architect" and "Landscape Architect" are both attempts to borrow gravitas without giving up up all of the art suggested by their original "Designer". Like "Agile" as a label, who wouldn't want to be An Architect?
I've started researching different metaphors, mapping their rises and falls in popularity. I have fifty years of past writings to dig through before I'll feel prepared to jump into the fray myself, but in the meantime I plan to share some of what I am discovering here. I've been intrigued in particular by some analogies that have been abandoned, and the ways that our analogies begin to fall apart as the fields we compare ourselves to integrate technology. Over the past thirty-five years building a house has become more like writing a program than writing a program has become more like building a house. Though they produce fewer good stories, collaborating with such hybrid professions may provide more practical improvements in the creation of software.