Software Development Is Neither Art Nor Science

The software development community has an axis of partisans that runs from those who want to view themselves either as free-wheeling creative types channeling form out of the aether and putting it beautifully, elegantly into code to those who view themselves as white-suited scientists or engineers reasoning natural laws and applying those laws to GUIs. Hence, we get a constant stream of articles like this one, “Software engineering: Art or science?” from the November 8, 2011, SD Times magazine. November 8? Jeez, how deep is the pile of things on the left wing of my desk?

Point of order, Mr. Chairman: Software development is neither art nor science.

Were it art, the product would be meaningful only in invoking thought or providing a comforting sense of beauty. I mean, you don’t use a painting or a concerto for something other than enjoying the painting or concerto. Unless you’re breaking prisoners of war with them or something.

Were it science, the product could be replicated over and over again by others in other organizations and come up with the exact same result. I’m not talking about duplicating CDs or packaging distros; I mean when one wanted to connect to a database, one would use the proven method that had been established, basically, by Isaac Newton. Software development is not that way; its experiments–that is, the development of individual projects or products–do not yield a similar result when done over a series of time and in different location.

What is software development, then? It is handicrafts.

  • The end product does something. The end of the coding process is not some pretty Matrix-drizzle of green numbers to make everything pretty. The end of the coding process is some sort of tool. Ergo, the application is not a work of art. While crafting often produces just art, in other cases it produces something that does something else, however twee. Quilting produces a device that retains heat; woodworking produces furniture. And so on.
     
  • The end product is unique. Assuming you’ve built a phonebook database, a Web site that allows users to enter into a sweepstakes, or a Web service that seeks and receives data from a database to dish to a presentation layer somewhere, you’ve built something different from all the others that have been built before, even those that do the exact same thing. If this were science, your process would yield a finished result that matched the others.
     
  • The end product bears certain trademarks of the craftsmen. Come on, your fingerprints and foibles are all over your software. The tweaks and ways you do things are different from everyone else’s, and someone who’s familiar with your work and with the industry will see your marks on what you’ve done.
     
  • Each end product will have unique defects. In handicrafting, it might be a little glue showing in the gaps of bonded surfaces, maybe a little nesting somewhere in a seam. Maybe they won’t be glaringly obvious, and only another craftsman will see them. Maybe they’re obvious enough that nobody will buy them from your table in the bazaar. Regardless, the defects will be unique to the product, and your other products even if they’re very similar products will have different defects. Or maybe you make the same mistakes over and over and your defects are your trademark.
     
  • Best practices and technologies are faddish. The things you’re coding in and the ways you’re doing it are not necessarily the end result of some evolution or even rational processes. They might just be what someone read in a magazine and thought would be worth a try. Evaluating the practices’ effectiveness might become secondary to trying something novel. I know how to paint the glass into which I pour my candles–what if I try etching the glass? What, indeed?
     
  • Truth does not determine what tools or technologies you use. You know, for that pyrography design, perhaps a wire nib is called for. However, your budget only allows enough for a cheap Walnut Hollow solid nib woodburning kit. As in software development, sometimes the “best” tool is the open-source product that meets some subset of your needs, but it’s free. So you make do. Like a scientist working with studying particles with a Moderately Sized Hadron Collider.
     
  • The craftsmen are more like gossipy ladies at the Singer sewing classes than steely-eyed doctors. I mean, granted, even steely-eyed scientists can be a gossipy lot, but. Any time your craftsmen speak from authority, they’re speaking from some experience, some faddish magazine or blog articles, and/or some education, but they’re not as ex cathedra as they’d like you to think.

Does the metaphor break down? Assuredly. I am a mere craftsman. But if you try to pour software development into some metaphor to make it comprehensible to non-IT people, you could do worse. Like saying it’s an art or a science.

3 Responses to “Software Development Is Neither Art Nor Science”

  1. jstrazzere Says:

    Well said, Brian!

    I completely agree that software development is neither art nor science. I just wish that “handicrafts” had an equivalent term with more business connotation.

    For me, handicrafts are a leisurely activity, driven more by a desire to produce something “interesting” (to me). On the other hand, pretty much all the software development and testing work I do is driven by business needs.

    Still, nice article – and with very little in the way of hate included!

  2. The Director Says:

    Business needs. Ah, you slay me.

    Don’t you think that too much in the industry, the direction has been to give the developers a hand in doing what they think is cool, too often at the expense of the business needs?

    I think we’ve got to keep an eye–and an iron hand–on that.

  3. Revue de Presse Xebia | Blog Xebia France Says:

    […] mettons cette semaine en avant deux entrées de blog pour nous aider à avancer sur le sujet. Le premier article postule que le développement informatique ne peut-être vu ni comme un art ni une science. […]


wordpress visitors