I know I’m fakin’ it,
I’m not really makin’ it.
This feeling of fakin’ it—
I still haven’t shaken it.
The biggest myth about engineering design is that it is somehow a ‘rational’ process. David Parnas and Paul Clements begin their now-classic paper ‘A Rational Design Process: How and Why to Fake It’ by claiming that ‘A perfectly rational person is one who always has a good reason for what he does’.2 [2 David Lorge Parnas & Paul C. Clements, ‘A Rational Design Process: How and Why to Fake It’, IEEE Transactions on Software Engineering Vol. 12, No. 2 (1986), pp. 251–256.] That already calls into question the utility of the term, given that there is already a word in ‘rational design process’ that means always doing things for a good reason: ‘design’. Tautology aside, this definition is most notable for what it fails to tell us about the design process. What if there is also a good reason in favour of an alternate—maybe even the opposite—course of action? What if there are good reasons against every available option? How is a ‘rational’ designer to resolve these contradictions?
These are not merely theoretical questions. Certainly, there are design decisions that rest on a choice between an unambiguously good option and an unambiguously bad one, but there are no books written, no articles published and no breath wasted on them. Even if some irrational lunatic should make the ‘wrong’ choice, we would be well advised to reconsider what might have led them to do so before consigning them to a rubber room. All interesting design questions are left unresolved by the facile advice to make good decisions instead of bad ones.
The requirements for design conflict and cannot be reconciled. All designs for devices are in some degree failures, either because they flout one or another of the requirements or because they are compromises, and compromise implies a degree of failure.
Failure is inherent in all useful design not only because all requirements of economy derive from insatiable wishes, but more immediately because certain quite specific conflicts are inevitable once requirements for economy are admitted; and conflicts even among the requirements of use are not unknown.
It follows that all designs for use are arbitrary. The designer or his client has to choose in what degree and where there shall be failure. Thus the shape of all designed things is the product of arbitrary choice. If you vary the terms of your compromise—say, more speed, more heat, less safety, more discomfort, lower first cost—then you vary the shape of the thing designed. It is quite impossible for any design to be ‘the logical outcome of requirements’ simply because, the requirements being in conflict, their logical outcome is an impossibility.
Designs are not the product of pure ratiocination—‘the logical outcome of the requirements’—they are arbitrary. Arbitrary, perhaps, though not through capriciousness. For the designer always makes a choice for a good reason; what we cannot expect is that all designers will make the same choices for the same reasons. Design is not repeatable.
Engineering design is always a contingent process, subject to unforeseen complications and influences as the design develops. The precise outcome of the process cannot be deduced from its initial goal. Design is not, as some textbooks would have us believe, a formal, sequential process that can be summarised in a block diagram. … Although many designers believe that design should work this way, even if it doesn’t, it is clear that any orderly pattern is quite unlike the usual chaotic growth of design.
Although it is never mentioned explicitly, the Rational Design Process we are talking about here is, in fact, the Process Formerly Known as the Waterfall Method.5 [5 This is not to be confused with the Rational Unified Process, a methodology promoted by IBM subsidiary Rational Software.] As the paper states, ‘[a]ll methodologies that can be considered “top down” are the result of our desire to have a rational, systematic way of designing software’—which is quite true, though nearly a quarter of a century later it is no longer the ringing endorsement it must have seemed at the time.
The authors are having none of this, however. They wisely spurn the idea of the design process as morphology. The impossibility of carrying out a project ‘in the “rational” way’, they claim, is ‘quite obvious, known to every careful thinker, and admitted by the honest ones.’ History records that even amid the ridiculous assembly-line analogies of the first Nato Software Engineering conference in 1968 there were careful thinkers to whom this was well known:
The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.
—Douglas Ross6 [6 Peter Naur & Brian Randell (eds.), ‘Software Engineering’ (Nato Scientific Affairs Division, 1969), p. 32.]
Engineers such as Ferguson and Billy Vaughn Koen paint a very different picture of the engineering method from the top-down ‘rational’ process which purports to proceed systematically from the final form of the artefact to a completed design. To Koen, the final form emerges from a design process driven by a set of heuristics unique to each designer.
From the time of Socrates to the work of Polya7 [7 George Pólya, How To Solve It (Princeton University Press, 1945).], the heuristic method was considered as an alternative strategy for pointing the way to the true state of affairs. The implicit understanding was always that there was a true state of affairs to point the way to and that the heuristic method was one of many that could be used. When we use the heuristic method in engineering, we do not admit that another method is possible, much less more desirable, or that a solution independent of the one defined by the method exists.8 [8 Billy Vaughn Koen, Discussion of the Method (Oxford University Press, 2003), p. 93.]
At this point, though, things take a turn for the weird. Having declined to build castles in the air, Parnas and Clements now express a desire to live in them regardless.9 [9 In the punchline to this joke, vendors of Case tools (for instance, IBM Rational) attempt to collect the rent.] The solution, considering the previous broadside against intellectual dishonesty, is even more peculiar: apparently we should just fake it.10 [10 The Unified Process is actually the best known example of a ‘faking’ methodology. In essence, it consists of a bizarrely sophisticated framework for generating bogus status reports. See also Mary B. Poppendieck and Thomas D. Poppendieck, ‘A Rational Design Process—It’s Time to Stop Faking It’ (2001).]
I find none of the supplied justifications for this fakery convincing, but none quite so unconvincing as the third: ‘When an organization undertakes many software projects, there are advantages to having a standard procedure. … If we are going to specify a standard process, it seems reasonable that it should be a rational one.’ Or, to paraphrase: ‘This process is the best because we have to follow some process and this one is clearly the best.’ Students of logic know this line of argument as ‘begging the question’; children know it as ‘because I said so’.
The whole exercise, far from being rational, is an attempt to rationalise the authors’ ongoing faith in the prevailing fashion for top-down design in the face of their own admission that it is demonstrably incorrect. ‘The first principle’, Richard Feynman said, ‘is that you must not fool yourself—and you are the easiest person to fool.’11 [11 Richard P. Feynman, ‘Cargo Cult Science’, Caltech Engineering and Science Vol. 37, No. 7 (June 1974), p. 12.] Once you pretend to know what you are searching for, all is lost.
Contemplating this strange fantasy, I cannot but recall P. J. O’Rourke’s quip that ‘With Epcot Center the Disney corporation has accomplished something I didn’t think possible in today’s world. They have created a land of make-believe that’s worse than regular life.’12 [12 P. J. O’Rourke, Holidays in Hell (Vintage Books, 1989), p. 184.] The make-believe land of perfect rationality strikes me as in every way worse than regular life. O’Rourke, however, was betraying a distinct lack of imagination: the same would be true of any make-believe land.
Take, for example, the popular imagery of heaven.13 [13 Note that this imagery is rooted in culture and has very little basis in theology.] You have the featureless cloudscape, the ubiquitous white garb, the incessant harp music and the exclusive company for all eternity of those who have led blameless lives. If there were an eighth circle of hell, it surely could be no more insufferable than this.
In every age someone, looking at Fedora as it was, imagined a way of making it the ideal city, but while he constructed his miniature model, Fedora was already no longer the same as before, and what had been until yesterday a possible future became only a toy in a glass globe.
The common error of most utopists, Koen observes, is to see the world as fixed, unchanging.15 [15 Koen, Op. cit., pp. 233–236.] ‘They have little sense of continual change, even less sense of transition from our world to theirs, no sense of history, and an obnoxious sense of self-righteousness.’ The real world in its present state results from the evolution of a complex and highly-interconnected system whose stability is maintained by numerous feedback loops. One need not live long in another country, or even merely another city, to see how this process has played out differently in different places according to different conditions.
One constant source of irritation to me is people who complain that software engineering is insufficiently mature.16 [16 To pick one example among many: Christof Ebert, ‘The Road to Maturity’, IEEE Software Vol. 14, No. 6 (November 1997), pp. 77–82.] Perhaps what irritates me most is that they are correct: software engineering really is immature. The dominant software engineering paradigm, which might best be described as Fad-Driven Development, represents a typically adolescent pattern of behaviour from an industry that is still struggling to find its identity.
If software engineering is in its adolescence, however, the critics’ proposed cure is downright childish. A child may naïvely wish to be transported to a fantasy world where every day is sunny, but as adults we accept a little rain must fall that we might grow grass to feed our ponies.17 [17 For a full exploration of the unintended consequences of ponies, see Graham Greene, Our Man in Havana (Heinemann, 1958).] On the road to maturity we put away such childish things as the idea that the world could be simple, if only we pretend fervently enough.
Utopian step changes to the system that discard feedback loops are as far from the basis of good engineering practice as it is possible to get: ‘they violate nearly every known heuristic of engineering.’18 [18 Koen, Op. cit.] Nobody becomes an engineer with a panglossian belief that we live in the best of all possible worlds. Yet we must not fear the real world and seek to retreat into a land of make-believe, for the very thing that makes engineering necessary also makes it possible.
Change; complexity; uncertainty: these things are the stuff of life itself. Tire of them and you are tired of living. You may credibly claim to prefer a kind of Platonic rationalism only if, like the philosopher Arthur Schopenhauer, you ‘look upon life as an unprofitable episode, disturbing the blessed calm of non-existence.’19 [19 Arthur Schopenhauer, Studies in Pessimism (Swan Sonnenschein, 1908), p. 14.]
Here, then, is the truly pervasive myth of rational design. Not that it is possible—Parnas and Clements were right: only cranks actually believe that. The myth is that it is desirable; that it represents an unattainable ideal rather than an intolerable abomination; that the world would be better if we all saw it through the dead-eyed lens of reason. This I reject.
