8. Rationalism versus Empiricism in Design
John Locke (1632–1704), British empiricist philosopher
Wikimedia Commons (commons.wikimedia.org)
All Men are liable to Error; and most Men are, in many Points, by Passion or Interest, under Temptation to it.
JOHN LOCKE [1690], AN ESSAY CONCERNING
HUMAN UNDERSTANDING
... the two operations of our understanding, intuition and deduction, on which alone we have said we must rely in the acquisition of knowledge.
RENÉ DESCARTES [1628], RULES FOR
THE DIRECTION OF THE MIND
Rationalism versus Empiricism
Can I, by sufficient thought alone, design a complex object correctly? This question, particularized to design, represents a crux between two long-established philosophical systems, rationalism and empiricism. Rationalists believe I can; empiricists believe I cannot.1
The crux goes much deeper than first meets the eye. The philosophical issue is fundamentally one’s view of the nature of man as creator.
The rationalist believes that man is inherently sound (and good), subject to mistakes, and perfectible by education. After right education, maturing experience, and sufficient careful-enough thought, a designer can make a flawless design. The design methodology task, therefore, is to learn how to reason a design into flawlessness.
The empiricist believes that man is inherently flawed, and subject repeatedly to temptation and error. Anything he makes will be flawed. The design methodology task, therefore, is to learn how to determine the flaws by experiment, so that one can iterate on the design.
Examples abound. Aristotle believed he could discover science deductively by reasoning; hence heavier objects would fall faster than light ones. Galileo believed that experiment was necessary and had the temerity to challenge Aristotle’s ancient authority.
René Descartes (1596–1650) perhaps most directly enunciated the rationalist view. John Locke (1632–1704) clearly set forth the empiricist one.
To this day, French science excels in beautiful logical structures, from Fourier’s analysis of heat flow, through Carnot’s thermodynamics, to the mathematical edifices of the Bourbaki group. Meanwhile, British science has gone from strength to strength within the empirical tradition—Watt, Faraday, Heaviside, the Braggs all leap to mind.
Software Design
Is a computer program a mathematical object to be fashioned in abstraction and made correct by proof? So the rationalists would contend, led by Edsger Dijkstra.2 It is all a matter of proper careful thinking. One can, and should, design software to be correct and then prove the design is correct. And that will suffice.3
Now, granted, a program is a pure mathematical object and in principle can be designed perfectly by correct thought. The difficulty is not with the design medium but with designers. Empiricists believe that humans will inevitably make mistakes: in defining objectives, in software architecture, in implementation in objects (algorithms and data structures), and in realization in code itself. This firm faith in fallibility prescribes a design methodology that includes design, early prototypes, early user testing, iterative incremental implementation, testing on a rich bank of test cases, and regression testing after changes.
I Am a Dyed-in-the-Wool Empiricist
I became so first from experience. Only twice in my life have I written a program that ran correctly the first time and did exactly what I needed it to do. One of those times was my very first substantial program. In graduate school at Harvard in 1953–1954, we had programming term projects. The mode of use of the Harvard Mark IV was hands-on, but each team of two students got two one-hour shots in which to debug and run their semester projects. William V. (Bill) Wright, a super-able peer, and I desk-checked our modest 1,500-line program meticulously and ad nauseam. It ran right the first time.
One might say that this experience is an existence proof for the possibility of rational design for correctness. But we didn’t prove our program correct; we desk-tested it by simulated execution. Moreover, I doubt if anyone could maintain the state of motivation and regularly repeat the level of meticulous checking that we did. Yes, in principle it is possible. With real people and real-scale contemporary software, it is not sustainable.
What is the experience in designing programs to be correct? People have used formal proof methods to prove that the kernels of secure operating systems are correctly designed and implemented.4 This is an exactly proper use of the technique. One needs the high degree of assurance that a formal proof offers.
Even that assurance is not 100 percent, of course. Over the history of mathematics, many proofs, once accepted, have later been found fallacious.5 Formal proof is not an error-free technique. Its advantage is that the reasoning in a formal proof is different in form from that of program design, so the odds are radically improved that the same mistake will not slip past both scrutinies.
The kernel is probably as far as the correctness proof technique should be applied. If kernels are secure and correct, the damage of error, loophole, or malice elsewhere in the program can be contained. The work of proving a program correct is substantial, on the order of the work of building the program. No proof can show that the original objectives for the program were right.6
Harlan Mills and his colleagues at IBM developed a variant of design correctness-proving that makes a lot of sense to me. In their “cleanroom” technique, Mills and team expose every aspect of a design to intense group scrutiny. The design group, in meeting assembled, hear the designer explain why the design is correct, as they challenge his arguments and their implicit assumptions.7
Formal proof of correctness is usually infeasible; abandoning all effort at systematic verification (the more common extreme) is dangerous: Mills’s systematic but non-formal group scrutiny of logical argument seems to me a wise and practical balance.
Rationalism, Empiricism, and Correctness in Other Design Domains
So far as I can tell, in no design domain other than software engineering have designers even attempted to prove correctness by rigorous formal methods. Perhaps this is because software is, like mathematics, fashioned of pure thought-stuff, so rigorous proof is conceivable. Most other design domains result in physical implementations, and one cannot prove theorems about materials and their faults, or about spaces and their suitability.
Organization design is like software design in that no material is involved. I know of no attempt to prove correctness, or even workability, of a postulated organization. The authors of the The Federalist Papers, however, undertook to demonstrate the feasibility of the United States Constitution by closely reasoned logical arguments. Whereas much of their wisdom still impresses succeeding generations, the Civil War (a system crash of extreme severity) demonstrated the incompleteness of the demonstration.
Design domains other than software engineering may not undertake correctness-proving, but they make extensive use of design verification, using a myriad of analysis and simulation techniques.
People now do stress, vibration, acoustic analyses on mechanical parts. Real-time or videotaped walk-throughs enable architects and clients to run simulated use scenarios on designed buildings. Loading-stress analyses test against snow and hurricane. Earthquake analyses provide dynamic stress testing.
Computer hardware undergoes extensive simulation at the circuit level, the logical design level, and the program execution level. Even the operating system for a not-yet-built computer is extensively tested; it is executed (dead slow) on a computer simulator on an existing host.
An inevitable consequence of these extensive empirical analyses is greater iteration in the design process. The more sophisticated analysis means more precise measures of the degree to which desiderata have been satisfied and constraints obeyed. Hence verification of the design against the goals specified becomes a more straightforward and certain process. But none of these analyses and simulations addresses the rightness of the goals or the validity of the assumptions about the environment.
Can I, by sufficient thought alone, design a complex object correctly? No; testing and iteration are in practice necessary. But careful thought helps. The succeeding essays in Part III suggest some aspects of such thought.
Notes and References
1. Rationalism and empiricism are approaches to epistemology—how one can know something. The classic propounders of these positions were far from polarized. Descartes advocated empirical science; Locke saw rationalism as the basis for mathematics.
This particularization from epistemology to design is my own; I am in deep water here and quite subject to error.
2. Dijkstra [1982], Selected Writings on Computing.
3. Dijkstra [1968], “A constructive approach to the problem of program correctness,” 174–186.
4. Klein [2009a], “Operating system verification,” and [2009b], “seL4: Formal verification of an OS kernel,” gives a good overview and an impressive current achievement. The authors claim this as the first time that a nontrivial kernel’s implementation has been completely functionally verified.
5. For example, there was a proof that a matrix multiplication requires n3 scalar multiplications. The flaw was in the assumption that the operations would be on vectors. Strassen [1969], “Gaussian elimination is not optimal.”
6. A famous and instructive case is the accident of Lufthansa Flight 2904, which went off the runway at Warsaw due to a failure of the computer-controlled stopping systems to engage. The code followed the specification, which was wrong for the unexpected circumstances. According to http://en.wikipedia.org/wiki/Lufthansa_Flight_2904, referenced on July 16, 2009:
To ensure that the thrust-reverse system and the spoilers are only activated in a landing situation, all of the following conditions have to be true for the software to deploy these systems:
• there must be weight of over 12 tons on each main landing gear strut
• the wheels of the plane must be turning faster than 72 knots
• the thrust levers must be in the reverse thrust position
In the case of the Warsaw accident neither of the first two conditions was fulfilled, so the most effective braking system was not activated. Point one was not fulfilled, because the plane landed inclined (to counteract the possible windshear). Thus the pressure of 12 tons on both landing gears required to trigger the sensor was not reached. Point two was also not fulfilled because of a hydroplaning effect on the wet runway.
7 Mills [1987], “Cleanroom software engineering.”
Wikipedia (referenced on October 30, 2008 at http://en.wikipedia.org/wiki/Cleanroom_Software_Engineering) provides a good summary of the whole approach:
The basic principles of the Cleanroom process are
Software development based on formal methods
Cleanroom development makes use of the Box Structure Method to specify and design a software product. Verification that the design correctly implements the specification is performed through team review.
Incremental implementation under statistical quality control
Cleanroom development uses an iterative approach, in which the product is developed in increments that gradually increase the implemented functionality. The quality of each increment is measured against pre-established standards to verify that the development process is proceeding acceptably. A failure to meet quality standards results in the cessation of testing for the current increment, and a return to the design phase.
Statistically sound testing
Software testing in the Cleanroom process is carried out as a statistical experiment. Based on the formal specification, a representative subset of software input/output trajectories is selected and tested. This sample is then statistically analyzed to produce an estimate of the reliability of the software, and a level of confidence in that estimate.