The Origins of JSP and JSD: a Personal Recollection
Michael John Jackson · 2000
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. In 1964 I went to work at John Hoskyns and Company, a new consultancy in London. Seeking a more reliable and systematic way of programming, we spent a lot of time thinking about the problems of program design. In those days disk drives were quite new, and most often used to hold sequential files like the tape files that were the standard basis of data processing systems. So program design seemed to be chiefly about sequential processes. Barry Dwyer joined the company in 1966, and Brian Boulter joined soon after. We worked together on improving our design methods. We experimented with top-down decomposition, and with some notions rather similar to coupling and cohesion; but they didn't seem to hold the key to design. Eventually we saw, in somewhat vague terms, that the coding discipline of structured programming invited the adoption of a hierarchical program structure to match the structures of the data files. Sometimes those data structures were mutually incompatible, but we weren’t sure how to handle this difficulty. We also recognised — it was Barry's idea — that backtracking was an important technique, seemingly ignored by everyone else, practitioner or academic, working on program design methodology. A vital stimulus to our work on program design was a project ─ ‘the Microsystem’ ─ that we did for a large insurance broker. The application demanded daily processing of small numbers of many different transaction types, each with its own pattern of access to the many master files. An on-line transaction-based solution was not economically practical at the time; and the low volumes and varied access patterns made it impossible to design an efficient batch system. The Microsystem worked as a dynamically scheduled batch system. Transactions were run against one