Can We Find Better Software Development Metaphors

As developers we work in the world of the abstract. Often we spends days producing software that sits behind the scenes and is only barely tangible. With this as a back drop, it is not surprising that we make heavy use of metaphor when discussing what we do and why we do it. For a long time we have plundered the language of the building trade (architecture documents, engineering etc.). More recently the ‘craftsmanship’ movement has had a good rummage in the artisan’s toolbox.

Each metaphor has its strengths but also its weaknesses. Craftsmanship can go two ways; for some it describes the elegant piece of joinery that uses materials effectively to produce a simple and practical piece of furniture that will last a life time, but for others it is suggests overly meticulous fiddly finery that produces beautiful but massively overworked rococo masterpieces (or monsters in our world). Equally, heavy upfront architecture has its fans and its critics; to some extent the background argument is about how appropriate the architecture metaphor is to a particular scale of project.

So maybe it is time to explore a new source of metaphors. Listening to the Reith lecture given by Atul Gawande this morning I was struck by a couple of paragraphs that could have been written (well almost) about good software practice.

But just because you have a roadmap does not mean anyone is going to follow it. There are barriers to overcome to execute even the simplest step, and those barriers differ from place to place. In one health centre, staff may not wash hands because they don’t know it’s important; in another, because they don’t have sinks or running water in the delivery rooms; and in another, because they simply have not made it their habit and no one cares.

That last phrase I think is the critical one: if no one cares when someone takes the trouble to do things right, nothing changes. And the overwhelming message to the people who work at the frontlines of care around the world is that no one notices excellence and no one cares. That is the biggest source of burnout and discouragement for health care workers everywhere.

With due deference to the importance of the work described in this quote, I am beginning to think that medical language may be a richer seam of metaphor of exploring the wider context of development.

The quote talks about tools, practices and culture. These are also the three cornerstones of good software development. But we can take it a little beyond that. We can think about the difference between a Victorian backstreet sawbones that ‘gets the job done’ and a modern surgical team in a well-equipped suite. If we just focus on the operation performed and the short-term effect, they have a passing similarity.

When we talk about development we tend to focus on the software being changed, rather than the environment in which it is changing. To make the change hygienic we need to step back and extend our focus to include the environment. We need to make sure the working environment is ready before we start work (CI servers, unit tests, functional tests). We need to take professional pride in the careful maintenance of that working environment and we need the audit the trail to keep us accountable. I’m sure there are other ways we could play with this metaphor. Are there more you can think of, or maybe you can suggest an entirely alternative source of interesting development metaphors.

I intend to explore some closely connected metaphors, like the different types of contagion that can occur between code bases and surgical intervention as a metaphor for the defect detection/diagnosis/remedial cycle in follow up posts, so come back soon.