Michael A. Jackson

Michael A. Jackson (born 16 February 1936) is an independent computing consultant in London, England. He is also part-time researcher at AT&T Labs Research, Florham Park, NJ, U.S., and visiting research professor at the Open University in the UK.

Quotes

• A development method may be regarded as a path or a procedure by which the developer proceeds from a problem of a certain class to a solution of a certain class. In trivial cases, the method may be fully algorithmic; for example, there is an algorithmic procedure for obtaining the square root of a nonnegative number to any desired degree of accuracy.
  • Michael A. Jackson. "A system development method," in: Tools and notions for program construction: An advanced course, Cambridge University Press, 1982. p. 1

• My first serious programming work was done in the very early 1960s, in Assembler languages on IBM and Honeywell machines. Although I was a careful designer — drawing meticulous flowcharts before coding — and a conscientious tester, I realised that program design was hard and the results likely to be erroneous. Into the Honeywell programs, which formed a little system for an extremely complex payroll, I wrote some assertions, with run-time tests that halted program execution during production runs. Time constraints didn't allow restarting a run from the beginning of the tape. So for the first few weeks I had the frightening task on several payroll runs of repairing an erroneous program at the operator’s keyboard ¾ correcting an error in the suspended program text, adjusting the local state of the program, and sometimes modifying the current and previous tape records before resuming execution. On the Honeywell 400, all this could be done directly from the console typewriter. After several weeks without halts, there seemed to be no more errors. Before leaving the organisation, I replaced the run-time halts by brief diagnostic messages: not because I was sure all the errors had been found, but simply because there would be no-one to handle a halt if one occurred. An uncorrected error might be repaired by clerical adjustments; a halt in a production run would certainly be disastrous.
  • Michael A. Jackson (2000), "The Origins of JSP and JSD: a Personal Recollection", in: IEEE Annals of Software Engineering, Volume 22 Number 2, pages 61-63, 66, April-June 2000.

• After forty years of currency the phrase "software engineering" still denotes no more then a vague and largely unfulfilled aspiration.
  • Michael A. Jackson, cited in: Matti Tedre. The Science of Computing: Shaping a Discipline, 2014, p. 135.

• One of the difficulties in thinking about software is its huge variety. A function definition in a spreadsheet cell is software. A smartphone app is software. The flight management system for an Airbus A380 is software. A word processor is software. We shouldn't expect a single discipline of software engineering to cover all of these, any more than we expect a single discipline of manufacturing to cover everything from the Airbus A380 to the production of chocolate bars, or a single discipline of social organization to cover everything from the United Nations to a kindergarten. Improvement in software engineering must come bottom-up, from intense specialized attention to particular products.
  • Michael A. Jackson in: K. De Grave (ed.) Formalism & Intuition in Software Development; A conversation with Michael A. Jackson conducted by Edgar G. Daylight and Bas van Vlijmen. 2015

Principles of program design, 1975

Michael A. Jackson. Principles of Program Design, Academic Press, 1975

• The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work.
  • As cited in: Allen Kent, ‎James G. Williams (1995), Encyclopedia of Computer Science and Technology: Volume 32. p. 187

• We follow two rules in the matter of optimization:

Rule 1: Don't do it.

Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.

Quotes about Michael A. Jackson

• Jackson System Development (JSD) and Object-Oriented Design (OOD) have one major - arguably central - principle in common; namely that the key to software quality lies in the structuring of the solution to a problem in such a way as to reflect the structure of the problem itself. There should be a simple and demonstrable correspondence between a (real world) component of the problem and a (software) component of the solution. The two methods also use similar concepts to describe the problem domain (or 'real world'). It is considered to consist of identifiable objects ('entities' in JSD) and operations that are either performed or suffered by these objects ('actions' in JSD}.
  • Alan Birchenough and John R. Cameron. "JSD and object-oriented design." in: JSP & JSD-The Jackson Approach to Software Development (1989): 292-304. p. 305.

• Systems engineering as an approach and methodology grew in response to the increase size and complexity of systems and projects. It "recognizes each system is an integrated whole even though composed of diverse, specialized structures and sub-functions..." (Chestnut, 1965) This engineering approach to the management of complexity by modularization was re-deployed in the software engineering discipline in the 1960s and 1970s with a proliferation of structured methodologies that enabled the the analysis, design and development of information systems by using techniques for modularized description, design and development of system components. Yourdon and DeMarco's Structured Analysis and Design, SSADM, James Martin's Information Engineering, and Jackson's Structured Design and Programming are examples from this era. They all exploited modularization to enable the parallel development of data, process, functionality and performance components of large software systems. The development of object orientation in the 1990s exploited modularization to develop reusable software. The idea was to develop modules that could be mixed and matched like Lego bricks to deliver to a variety of whole system specifications. The modularization and reusability principles have stood the test of time and are at the heart of modern software development.
  • Peter Allen, Steve Maguire, Bill McKelvey (2011) The SAGE Handbook of Complexity and Management. p. 35