Simplicity

Tony Hoare [1] managed the development of the promised software for the Elliott 503 Mk II computer. In 1964 the project ended in disastrous failure. He identified the fundamental cause only when his most senior manager shouted at him ‘You let your programmers do things which you yourself do not understand!’—he had strayed from the narrow path of simplicity.

Simplicity is the antithesis of complexity. Not of computational complexity, which measures the time or space consumed by an algorithm, but of the complexity which resists human understanding. Structured programming, in Dijkstra’s sense, embraces simplicity. Progress in program execution is directly mapped to the program text; the execution context of every segment of code is clearly visible in the nested enclosing segments. A structured program is comprehensible: its readers understand its behaviour well enough to enact it in their minds as they read.

The machine program of a triplet should be a structured program. In the same way, a triplet’s model of the governed world, and its behaviour operational principle, must be simple. An interesting departure from simplicity of operational principle is apparent in the classic pendulum clock. Most causal links in the clock's operational principle are clear: the weight or spring turns the gear train; the gear train turns the hands; the force of gravity acts on the pendulum; and so on. But the escapement presents a complexity. Here the pendulum acts on the escape wheel to ensure timely controlled rotation of the gear train; but also the escape wheel acts on the pendulum to maintain its swing against the resistance of air pressure and friction. The operational principle reveals this problem explicitly. Horologists worked on this probem for centuries, proposing and improving mechanism designs, eventually trying to dissolve the mechanical conflict by electromagnetic coupling. (For a software taste of this kind of complexity, try designing a driver assistance behaviour that combines speed limiting with cruise control.)

Simplicity must also be sought more generally in the governed world model. Domain properties must hold, as described, over the whole behaviour enactment. Each domain must play a constant role over the enactment (setting the clock and tuning the radio can't appear in the same behaviour for the Honda Jazz, because the tuning buttons domain is also used to set the clock time). The enactment time span must be unbroken: the machine may sometimes wait for the governed world, and vice versa, but there must be no time at which machine execution has been suspended for later resumption. The problem must be closed in the sense that the triplet behaviour can be deduced from its machine program and governed world model alone, without reference to properties of anything external.

There was a happy ending to the Elliott 803 story. Tony Hoare was given the opportunity to repair the catastrophe, and he succeeded. Twenty five years later [1], he summed up the lesson in a famous maxim. "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

[1] Tony Hoare; The Emperor’s old clothes; CACM February 1981. Reprinted in C A R Hoare and C B Jones; Essays in Computing Science; pages 1-18, Prentice Hall 1989.