Looking back: Software is Art?

The traditional craftsman uses handed down principles and rules of thumb as the basis of his work: experience gained over many years of apprenticeship. The engineer proves his designs at every stage with scientific laws and mathematics. Craft and engineering differ in their techniques but they have a common goal remain the same : to provide efficient, useful artefacts.

In Computer Programming as an art, Donald Knuth summarises this by saying, “Computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces object of beauty.”

The knowledge base that we have built up over thirty years is agreed to be incomplete. Reliance is often placed on software craftsmen, commonly known as ‘gurus’ or ‘hackers’ (in the programming world, a hacker is seen as a programmer of high esteem whereas it is the cracker who breaks into computer systems) – the reputation of some gives them almost hero. Robert Baber suggests that when software development progresses to be a true engineering discipline, such characters will disappear to be replaced by ‘members of professional bodies’. If this is going to happen it is a long way off yet.

And what of software itself? Is software an art form? Knuth refers to ‘beautiful programs’, and it is true that an elegantly structured section of code may be a pleasure to look at, at least to another programmer! This point should not be taken too far: a motorway intersection may well be an object of beauty to another construction engineer, but it is probably not for the rest of us. Artistic qualities do however have practical value for software : an elegant program is reasonably likely to be a well-written, maintainable one. It would be worth considering the addition of a little ‘art’ at all stages of the software life cycle. For example:

1. In the specification phase, a common language document is used to show the producer’s understanding of the clients’ needs. A well-written specification will increase the chances that such requirements have been noted; a readable specification may well ensure that both parties read it at all.

2. Software architectures can be elegant or impractical. An elegant architecture is one which ensures that its subsystems work together smoothly and efficiently; an inefficient architecture will be the source of an unnecessary performance overhead.

3. Algorithms can be fluid, smooth in motion or clunky and slow. A well-written algorithm will be more efficient than a badly written one.

4. The code itself can read like a good book or a child’s first essay. If the code is not readable it will quickly become unmaintainable, especially if its author is no longer available to explain it. Code should be self-documenting. If it is not clear exactly what a given code section is doing then it should be rewritten. In the maintenance phase, the code should also explain how it has been modified, by whom and when.

The quality of the product is dependent on the experience of the software developers – and their management – at their craft. Such craftsmanship must be learned. And as we have already seen, there is not always the time or resources available to provide such training. Peopleware makes the point that developers should be considered as experts rather than resources, and should be given enough space and facilities to permit them to excel. In DeMarco and Lister’s experience, it is this which ensures the optimal productivity of development groups.

Today’s software developer is somewhere between a craftsman and an engineer, using both science and common sense in his work. Tomorrow’s developer may well be the perfectly trained engineer proving everything as he goes. But he is not there yet. At least for the moment, gurus are a necessity and ‘software beauty’ keeps our minds on the goal.

[[And the punchline: this was written in 1994, as part of a bigger piece entitled Craft or Science – Software Engineering Evolution.]]

Content Contributors: Jon Collins