I’ll begin my series with an observation that may seem obvious to you, depending on where you’re coming from: the activity of developing software is unlike anything else we humans do. And since it’s a relatively new activity, we tend to use other activities as metaphors to better understand what it’s like. All of these metaphors predictably break at some points, which shouldn’t be a big problem—except we often treat the metaphors as the real thing, going as far as naming our premier journals and conferences after one of them.
It’s about developing products, sometimes following a spec, so the first comparison that comes to mind may be a manufacturing process, or perhaps a construction site. But we can see that software development involves far more creativity and intellectual effort than the work at an assembly line, and that for many (most?) projects people don’t even know what they want at the start, so specs, if we insist on them, are necessarily deficient.
If we follow this train of thought we may realize that software development has more similarities with product design than with manufacturing. For software, the manufacturing process has been entirely automated, and it is nearly instantaneous; as if an automobile designer could tinker with a model, hit a button, and see a car materialize in front of her, ready to be taken out for a test drive. But product design is a terrible metaphor because, considering that software development is so commonplace nowadays, we probably know more about it than about the metaphor that is supposed to enlighten us.
Other observations lead to different metaphors. A developer writes code, and so we are tempted to compare software development with writing (but for teams of dozens or hundreds of people the image of the writer isn’t very useful). Software teams need to be creative, to interact intensely, and to have a diversity of skills, so a theatre troupe metaphor might be appropriate (though software development is normally more utilitarian than the theatre). I’ve read comparisons between some aspects of software development and farming, surgical teams, craftsmanship, capital, painting, games, bazaars, and jazz, among those I remember at the moment. They’re all useful images to some degree, but their abundance is a symptom of the conceptual difficulties we have in grasping exactly what is it that software development is about, and how should we try and make it easier for everyone.
What is most interesting to me is that the metaphors we use make some paths apparent while hiding others. They have important consequences both for software research and practice. I’ll return to this idea in upcoming posts.