This important book is the result of two interviews with Michael A. Jackson, conducted in 2013, for which Jackson rewrote and refined several parts of the transcripts. The interviews were very well prepared and excellent questions were asked.

Already when Jackson was a pupil at a public school in England, his teacher of mathematics--who happened to be Christopher Strachey--told his pupils about “Cantor’s enumeration of rationals, the cardinalities of infinite sets, etc.,” and taught them (in 1950-51) how to write programs using a little language for handling small integers. At that time, Strachey showed to Jackson his draughts-playing program written out in pencil in machine code, demonstrating an error in that program, and “was delighted in pointing out” that the error was in his specification rather than in programming--a very important distinction. Later, Jackson obtained degrees in classics (Oxford, where Tony Hoare was also a student two years ahead of him) and in mathematics (Cambridge).

In the early 1960s, when Jackson worked, in Assembler, on his second large computing assignment (a large and complicated payroll program), he checked in his program whether assertions on the values of local variables were satisfied; if not, the program execution stopped with a console message that was taken care of by Jackson who then tried in “real time” to see what was wrong, and made appropriate program changes with eventual success. The approach of checking assertions was not well known at all in those days and may be compared with an independently developed observation program [1] used for the same purpose.

In a paper published in 1968, Jackson noted that rigor and precision fail when the job to be programmed cannot be completely specified. Thus, “the relationship of informal reality to its description formalized for programming purposes is a large, very important and much neglected matter.” This still remains true today. Even so, creating a program that will satisfy a well-defined, clear, and precise specification is very far from being easy, and this is where approaches such as Jackson Structured Programming (JSP), as well as those of Dijkstra, Hoare, and others, collectively known under the name “structured programming” (for example, [2]), are essential for success. Jackson notes that all his numerous JSP courses were on paper, without terminals, slides, or a projector, and stresses: “you can surely see real value in insisting that confidence in a program design should rest chiefly on careful use of a solid design method rather than on testing.” He further observes that his work “has chiefly aimed at achieving simplicity by structuring.” This approach reminds us, in particular, of Dijkstra’s insistence on making explicit the (often tacit) program design considerations and design process.

In 1973, Jackson was invited to become a member of the International Federation for Information Processing (IFIP) Working Group 2.3 on programming methodology and observed its very high intellectual standards: “Contributions to discussions were more constructive, more knowledgeable and more thoughtful than the hurly-burly of arguments between advocates of competing software design methods and tools in the commercial marketplace.” This observation may also refer to some current more or less buzzword-compliant modeling methodologies, enterprise architectures, business architectures, and so on. For a more recent, and in my opinion outstanding, look at Jackson’s contribution to Working Group 2.3, see [3].

While formalism is essential for eliminating development errors, its primary use, as Jackson notes, “should be in a development context that has already been clearly structured by the use of intuition, experience and invention.” Somewhat more specifically, Bjørner suggests that “analysis & description is a trial-and-error, iterative process. During a sequence of analyses ... the analyzer ‘discovers’ either more pleasing abstractions or that earlier analyses or descriptions were wrong, or that an entity either need be abstracted or made less abstract. So they are corrected” [4]. Note the plural in “abstractions”: Jackson also stresses that multiple abstractions (for example, due to various viewpoints of different stakeholders [3]) are essential and that reconciling these abstractions (that is, different models of the informal world) “is a major design task.” Since understanding and structuring of the business problem comes first, care must be taken not to be seduced by technology (including methodologies and tools) or by mathematical formalisms. Many contributions by Jackson, especially his work on problem frames discussed at some length in this book, show how to do just that. His remark made in the keynote at the International Conference on Software Engineering, in 1995, is still valid: “the descriptions of the machine were often given under the pretense of describing the problem world--a kind of wolf in sheep’s clothing. This is especially true of object-oriented methods.” My experience suggests that to separate these concerns, that is, to prevent modeling a problem in terms of a solution (as “most software development techniques like UML” do), it may be required to disengage business subject matter experts from information technology experts. In this context, it is also important to emphasize Jackson’s observation, made already in 1983, that the model of reality is more stable than function, and therefore “by starting with one function you risk creating an arbitrarily limited model that is very hard to escape from later.” Many buzzword-compliant approaches fail for this reason.

Jackson observes that there has been “a harmful divide between the formalists and the intuitionists” in software development that has “seriously hampered the progress,” and that too few people are experts in both aspects. In 1969, this desideratum was discussed at the NATO Software Engineering Conference, for example, by Christopher Strachey:

You shouldn’t judge the contributions of computing science to software engineering on the 95 percent of computing science which is rubbish. You shouldn’t judge software engineering, from the high altitude of pure theory, on the 95 percent of software engineering which is also rubbish. Let’s try and look at the good things from the other side and see if we can’t in fact make a little bridge. [5]

Somewhat similarly, Sharp, at the same NATO conference, noted: “I don’t believe for instance that the majority of what Dijkstra does is theory--I believe that in time we will probably refer to the ‘Dijkstra School of Architecture.’” Half a century later, we can see the correctness of Jackson’s more current remark that “in computing, we are very foolish: we don’t encourage the study of computing history ... we have made too little effort to learn from the past ... from our own predecessors”: many classical outstanding contributions (together with their underlying concepts emphasizing simplicity and elegance) have now fallen into neglect and are often not referenced and not taught, being replaced with “relevant to industry” courses and projects having no theoretical foundation (Bjørner).

The book includes a nice index (with many page numbers shifted by one or two) and a 59-item reference list. Unfortunately, a page fell out of my copy after a single reading.

I would highly recommend this book.

More reviews about this item: Amazon