The main point of this paper is explained by the author in the following words: “[I]n short, to write useful software we must deal not only with the computer and its software, but also with the complexities of the natural world in which the application resides” (p. 14). This explains software writing problems in a specific area, but cannot explain why software that does not deal with the real world is just as difficult to write.

The paper consists of seven parts. Part 1 describes what the paper is about. In part 2, the author’s main points about software development are stated. Part 3 starts with a categorization of problems (such as calling a problem causal if the problem to be solved is based on physical causality), and proceeds with a discussion of what extra requirements may occur while solving a problem (for example, how to synchronize the external world with the state of the model).

In part 4, real problems are classified, and the author states that “a realistic problem is not stylized and simple.” Jackson further explains how problems are tackled by decomposition, and notes that this decomposition might not be in response to just the problem at hand, but may also be influenced by computational subproblems. Part 5 is an example of the design of an application steering water flow.

The beginning of part 4 seems to be controversial. The author’s statement that “many problems are of the one-off variety” does not suggest that developing software is difficult. The opposite holds: solving a problem once makes it much easier to solve a similar but slightly changed problem in the future.

Another quote about our profession: “We are like engineers who are willing to embark on the construction of a car offering also the added functionality of a crane” (p. 18). I cannot believe that all of our software is of the “all-in-one device suitable for every purpose” type. Of course, “featurism” is a real problem, but a great deal of very successful software is very simple (for example, the file and tool box approach in Unix, or spreadsheets), but flexible.

A good point is made regarding the fact that two different models must be dealt with, namely, a real-world model and a computational model, which have to be synchronized. The problems that arise from this are hard to underestimate.

In conclusion, I found this paper to be very interesting and thought provoking. That I disagree with some of the author’s observations just confirms this. The author provides a good overview of a specific problem in one area of software development, although the explanations are not fully convincing. Software steering the real world is often very elaborate and safe. Do you remember the last time you heard of a software problem while picking up your luggage or mail?