Tue Oct 13 22:29:17 BST 2009
I've been thinking of late about the lie concealed within the phrase software engineer. It's a term a use myself to describe the job I do, but it gives the false impression that the process of producing software is an engineering discipline when in fact it is rather closer to an art form.
Now, it could be said that any creative endeavour within the sphere of engineering could be seen to be an art, and that's probably true. There is certainly a beauty, for example, in the moving parts of a car engine; or in the graceful sweep of a suspension bridge. Yet I would argue that the scope for creativity within the design of bridges and car engines is far less than that of software. In engines and bridges we have many decades [1] of accumulated knowledge and experience which naturally inform the majority of design decisions. Furthermore, engines and bridges have a critical requirement of being realisable with the physical materials that actually exist: a gossamer-thin road bridge spanning one hundred miles of ocean may well be an elegant vision but it won't be practically viable. Compare these considerations with the production of a new piece of software: in this domain we have, at most, fifty years of prior experience; and in any decade period the state of the art advances so far as to revolutionise the base materials available to the designer. Just as experience and practicality combine to limit creative potential in more traditional engineering design, the ever changing, ever nascent nature of software development means that creativity is not only much more possible, it is almost a prerequisite.
The concept of software as an art form is not a new idea by any stretch. One of the core texts of the software engineering library, after all, is Donald Knuth's seminal The Art of Computer Programming. Despite this, the overwhelming perception of software that appears to be intuitive to project managers and the general public alike is that software is, and should be, a science. A process as straight-forward and predictable as the building of a house or turning a table leg. Perhaps in a hundred years or so, when we've built up sufficient experience of what works and what doesn't; when Moore's Law has stopped making the underlying technologies shift and expand like quicksilver in a glass tube; perhaps then the notion of software production as a science will be realistic[2]. Until then, it's art all the way, baby.
[1] In the case of car engines, it appears we have something almost one hundred and fifty years of prior art, whilst bridges certainly go back much further still. As an aside on the topic of car design, it is interesting to observe how standardised modern cars are in comparison to early designs which had many weird and wonderful driver interfaces, to say nothing of what went on under the bonnet. This tends to support my argument that creativity in a design field is naturally attenuated over time.
[2] Which is not to say that there isn't science in software, far from it. The field is awash with science and mathematics at every turn. However, the coal-face practise of pushing buttons until all the little ones and zeros are arranged in a pleasing pattern is a different matter. It's one of the most engaging aspects of software: art atop science.