Whether software is art or engineering is an old question, and a relevant one to understand how the construction of software artefacts differs from the construction of other kinds of artefacts, like bridges or cars.
Imagine a painter. How does the painter work? Does he have an idea about the final result of his work when he starts? If that would be the case, the work would not be really creative. It seems that, although he may start with an idea, the creative work happens while painting. For instance, to study the creation process associated with some works, specialists use x-ray to examine the paint layers (Studying Raphael: x-ray examination).
Now imagine that one of his paintings becomes widely known, and appreciated, and that someone identifies a business opportunity in selling reproductions using a technique that allows cheap mass reproduction with high quality: serigraphy. The process of producing the serigraphs is an engineering process, is repeatable, the cost of production is proportional to the number of produced copies, every copy has the same quality, an so forth.
What about software? Building software artefacts is it like painting an original or like the process of producing copies?
To find an answer to this question we should look at a 1974 categorisation of software systems by Lehman and Belady, formulated in their laws of software evolution. According to Lehman and Belady there are three categories of software systems: S, P and E.
- In S-systems the problem is formally defined. As an example of a S-system consider a math software library, which implements a stable specification that has been defined by mathematicians.
- P-systems implement requirements that are a model of the problem, not the problem itself. This occurs because, to be executable by a computer, the system needs to have precise semantics, but the problem cannot be fully specified, and so, software engineers build a model they believe captures the relevant aspects of the problem. A chess game is a P-system because we cannot completely specify how to win the game, but we can create models that have winning heuristics.
- E-systems, like P-systems, implement a model of the problem, but this model becomes part of the reality it is modelling. An automated stock trading software is a E-system, because, once the system goes life the market changes, which is the reality modelled by the system. Therefore, in E-systems the models becomes part of the reality it is modelling.
We will return to this categorisation in the Requirements Engineering topic, but now we look at these categories from the point of view of the difference between art and engineering.
You may have noticed that there are more language transformations in P- and E-systems, because, it is necessary, at least, to write the model of the problem, while in S systems the model is given to the software engineering, he only has to implement it. Additionally, in S-systems the semantic gap between languages is smaller, because we start from a formal language, and it is only necessary to transform it into another formal language. As I pointed out in Software Development as a Formalisation Process language transformation can introduce noise, and noise is error, but can also be a source of creativity. Therefore, when a software engineer is designing a model for P- and E-systems he can be creative and have impact on what is the problem (P-systems) and what should be the world which encloses the problem (E-systems).
So far, we have seen that language transformations, in particular when there is a significative semantic gap between them, allows creativity to happen. However, we have not fully addressed the distinction between art and engineering, because engineering requires creativity as well. To do so, we have to return to the example of the painting and its serigraphs. The production of the serigraphs follows a plan, the goal is well defined from the very begin and it is only necessary to implement it for each reproduction. So the engineering process associated with producing serigraphs, or the construction of a bridge, is like the implementation of a S-system, the clear separation of the design from implementation. However, when we start de development of P- and E-systems we have a goal but we are not completely sure about what the final result will be. The goal changes while being implemented. The final system is conceived while being implemented, something similar to how a painter works.
The tension between art and engineering is pervasive in the software engineering approaches and it stems from the fact that for most systems it is possible, and often unavoidable, to intertwine the understanding and specification of a problem with the construction of its solution. Note that since the solution of a step becomes the problem of another (The Scope of Software Engineering), this can occur in every language transformation.