Software development is unique

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.


About Jorge Aranda

I'm currently a Postdoctoral Fellow at the SEGAL and CHISEL labs in the Department of Computer Science of the University of Victoria.
This entry was posted in Academia, Software development. Bookmark the permalink.

7 Responses to Software development is unique

  1. Christoph says:

    Great observations. I’d like to add that the metaphors are often only intended to describe one aspect of the development process, and so you usually end up with a combination of (incompatible) metaphors. In the example of jazz, IBM uses this term to refer to the collaborative processes in software development (every project is a live performance, and you need the virtuosity of individuals as well as the collaboration between those individuals for a successful performance). Of course, a successful software project needs much more than just good collaboration.

    Adrian Cho, who is the development manager of Rational Team Concert at IBM and also the conductor of the Impressions in Jazz orchestra in Ottawa, recently authored a book on the parallels between the worlds of jazz, business and software, “The Jazz Process”. I think Peggy ordered a copy for the lab, so you will have a chance to take a look.

  2. Christoph says:

    HTML #fail

    The orchestra is called Impressions in Jazz, and their website is here:

    The book is called The Jazz Process, and its website is here:

  3. Matt Doar says:

    Hmm. Maybe the use of metaphors is just not helpful here.
    Looking forward to seeing the rest of the series.

  4. Rudolf Olah says:

    You should read some of EW Dijkstra’s writing, he says similar things.

  5. Pingback: Three paradigms on software development | Catenary

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s