13. Exemplars in Design
Pages from a Palestrina Mass copy in Bach’s own hand
Staatsbibliothek of Berlin
. . . [T]he vast field of possibility can only be searched if you have some idea in advance of what you are looking for. Without prestructures of some kind, you cannot know where to look, or whether you have found what you are looking for. This again seems to justify architects in bringing past solutions and notions of style to bear on the search . . .
BILL HILLIER AND ALAN PENN
[1995], “CAN THERE BE A DOMAIN-
INDEPENDENT THEORY OF DESIGN?”
Few Designs Are All-New
But These Surely Are Fun!
Rarely does one get to do a design that is entirely new. Imagine designing the first Earth-orbiting satellite, the first portable telephone, the first WIMP interface, the first air terminal, the first supercomputer!
The Common Lot
Usually, however, even novel designs derive from earlier artifacts intended for similar purposes and built with similar technology. The designer himself may have designed an earlier work; if not, he surely has seen, studied, and perhaps used some.
What then is the proper role of exemplars, precedents, in design? How should the designer study and use them? Should each design domain develop an accessible cumulative store of exemplars? How? Who?
The Roles of Exemplars
Exemplars provide safe models for new designs, implicit checklists of design tasks, warnings of potential mistakes, and launching pads for radical new designs.
Hence great designers have invested great efforts in studying their precedents. Palladio (1508–1580) not only studied Vitruvius [22 BC], he journeyed to Rome and measured and documented the surviving monuments, learning the most successful of the concepts and proportions evolved by the Romans of antiquity. From this tedious and unsung labor sprang not only his own original designs, but a design book that fathered a most enduring style of architecture.
Jefferson carefully studied not only Palladio’s books, but the buildings around him in Paris.1
Bach took an unpaid leave from his job and walked 250 miles to study the work and ideas of Buxtehude for six months. (He lost his job for overstaying his leave.) Bach proved to be a much greater composer than Buxtehude, but his surpassing excellence came from comprehending and using the techniques of his predecessors, not ignoring them.2
I argue that great technical designers need to do likewise, but that the hurried pace of modern design has discouraged this practice.
Besides what individual designers do, technical design disciplines eager to produce great designs need to develop accessible bodies of exemplars and knowledgeable critiques of them.
What about Computer and Software Design?
What is the state of exemplar-based design in the computer and software fields? I think a fair answer is that we are rather behind older design disciplines. We are coming along rather well in developing the art and the resources for exemplar-informed design. But many of our curricula do not yet emphasize it, and penetration into design practice is not yet high.
What Exemplars Do You Use?
Amateur designers and trained professionals in the older design disciplines differ substantially in their use of exemplars.
The amateur uses those exemplars he happens to have encountered in his own experience. The trained professional has been exposed to a far wider range: whole libraries of exemplars representing different eras, different styles, different schools of thought. At best, he has had expert-guided tours through these libraries, with his teachers highlighting the noteworthy characteristics and explicating differences.
Much design in the computer and software fields suggests the use of only exemplars encountered in personal experience; even our trained professionals are not studying the exemplars available.
Computers
Computer architectures reveal the profound influence of the machine on which the architect first had substantial programming experience. Thus the early DEC minicomputers have a strong flavor of the MIT Whirlwind; IBM’s System/360 is heavily flavored by the IBM 704 and 1401; the early microcomputers are clearly inspired by the DEC PDP-11.
One can also discern corporate memory—computers, unlike buildings, are designed by architects working within the implementing companies. They are more familiar, by explicit training and by informal culture, with their company’s predecessor machines than with those of competitors. The Intel microprocessors strongly reflect a particular corporate style.
Design by adaptation is common in this field. Successful computers breed families of compatible siblings and successors, usually designed by adding function to the earlier models.
Mass-Product Software
Products such as Microsoft Word have followed the design pattern of computers, with successive generations created by progressively modifying function and implementation. This has been well studied and documented by Lehman and Belady.3
Custom Application Software and Operating Systems
Historically, most custom application software and operating systems reflect chiefly the experience of their designers, rather than that of the whole discipline.
More recently, the documentation and teaching of patterns has provided cross-fertilization for the field. Gamma [1995], Design Patterns, is strong on data structures and component-level patterns; Buschmann [1996], Pattern-Oriented Software Architecture, deals with larger-scale, system-structure patterns. We need more descriptions of whole systems, explaining system concepts. By and large we have that for a few operating systems only.
Studying Design Rationales of Exemplars
How should designers study exemplars in their fields? To study an architecture, one can read the manual. To study an implementation, one can read maintenance documentation. But for overview, one has to study the technical papers and books about the products to get the rationales.
Most technical papers, however, emphasize the whats and give skimpy coverage to the whys. And many designs never get explicated by their original designers at all; the creators are too busy on their next designs.
The exceptions cluster around the early days of any technology and around later revolutions, when approaches vary widely and debates are hot. These papers, like reports of military victories, are always after the fact, and they are usually rationalized; that is, they are far more rational in retrospect than was the actual design process. For most of us, that process was rich with potholes, blind alleys, mistaken turns, and alterations of goals. We learn a lot from the few exceptions to this post hoc smoothing.
Computer processor architecture provides a fruitful example for a study of exemplars. The technology is recent enough that there were many venues and outlets for descriptions. The field began with a wide diversity of design approaches and has converged to a “standard architecture.” Blaauw and I elaborate on this evolution in Chapter 9 of our Computer Architecture [1997]. Revolutions—virtual memory, minicomputers, microcomputers, and RISC architectures—punctuated the historical development. Each occasioned fresh debates and hence stimulated fuller rationales.
First-Generation Computers
The most important computer paper ever written is
Burks, Goldstine, and von Neumann [1946], “Preliminary discussion of the logical design of an electronic computing instrument.”
It is an incredible piece of work—must reading for every computer scientist. It cogently sets forth the stored-program concept, the three-register arithmetic unit, and many other ideas besides. The coverage is complete; the reasoning, compelling.
Maurice Wilkes says of an earlier draft,
I sat up late into the night reading the report. ... I recognized this at once as the real thing, and from that time on never had any doubt as to the way computer development would go.4
Wilkes further says there that this paper sets forth the ideas generated at the University of Pennsylvania in discussions among Presper Eckert, John Mauchly, and John von Neumann. He regrets that the extremely fruitful ideas are usually credited to von Neumann alone and has been at some pains to correct this misunderstanding.
After “Preliminary discussion” appeared, many groups in many places started building stored-program computers, using vacuum-tube logic. The first successes were at Manchester, with a running but unusably small Baby, and at Cambridge, with the first useful stored-program machine, the EDSAC. These rationales are very well documented: Williams [1948], “Electronic digital computers”; Wilkes [1949], “The EDSAC.”
The most important early supercomputers are the IBM Stretch and the Control Data CDC 6600. Buchholz [1962], Planning a Computer System: Project Stretch, gives mostly rationale papers. However, the most noteworthy paper is Chapter 17, which describes a radically different sort of computer—a data-streaming coprocessor designed for cryptanalytic use—with hardly any description of the application or rationale for machine features.
The CDC 6600 quickly succeeded the Stretch as the world’s fastest computer and came to dominate scientific supercomputing. It is the ancestor of the Cray family of supercomputers. Thornton [1970], The Design of a Computer—The CDC 6600, gives lots of rationale.
Third-Generation Computers
Second-generation computer architectures ran out of gas; that is, they lacked enough address bits to handle the large memories that had become economical and indispensable. An incompatible break in many product lines’ architectures became inevitable, although painful. Fortunately, integrated circuits provided a large improvement in realization cost, and high-level languages enabled recompilation, so that the switch to new architectures could be afforded. New architectures occasioned new rationales.
Blaauw and Brooks [1997], Computer Architecture, while not a rationale book, nevertheless includes rationales for many of the System/360 architectural decisions. Those are the examples we could explicate from personal knowledge. Amdahl [1964] and Blaauw [1964] give abbreviated synopses of the System/360 rationale.
Virtual Memory
The Manchester Atlas introduced the automatic paging of blocks of instructions and data from a slower backing store into a smaller high-speed memory. Developers of time-sharing operating systems at Michigan and MIT soon proposed generalizing this concept into a full-fledged virtual memory, with vast namespace. GE and IBM built such computers. Again a revolution; again new rationales: Sumner [1962] (Atlas), Dennis [1965], Arden [1966].
The Minicomputer Revolution
Transistor-diode logic offered a radically cheaper way of realizing computers. Such a machine, the DEC PDP-8, changed the world by making a computer that individual departments, not whole institutions, could afford and control. This sociological advance was at least as important as the technological performance/cost advance. Minicomputers were made by the thousands, coexisting with, rather than replacing, the so-called mainframes.
The mainframe makers were content with their business models, and—fat, dumb, and happy—they universally missed the minicomputer revolution. Many new computer makers started up. The most successful was Digital Equipment Corporation. Bell [1978] treats the rationales and evolution of DEC’s minicomputers.5
The Microcomputer and RISC Revolutions
A similar sociological and technological revolution took place with integrated circuits. Radically lower costs meant that individuals, rather than departments, could have and control their own personal machines. Microcomputers are made by the millions.
This time it was the minicomputer makers, quite successful at what they were doing, who were fat, dumb, and happy. They missed the microcomputer revolution. Hewlett-Packard survived; DEC did not. Some of the mainframe makers, notably IBM, got back into the game and became major suppliers of personal microcomputers.
Again, the revolution spawned a cascade of rationales: Hoff [1972] (one-chip CPU), Patterson [1981] (RISC I), Radin [1982] (IBM 801).6
Experts in other disciplines can readily develop similar lists, giving the flow of history, the revolutions, and the milestone documented exemplars.
What Should a Discipline Do to Improve Exemplar-Based Design?
If indeed designers need to thrust beyond their own personal and corporate experience to master the ideas and techniques of their whole craft, how can the craft help?
Collections of Exemplars
The foregoing section shows that for computer architecture, there are plenty of documented exemplars. The obvious next step is the assembling and publishing of systematic collections. Gordon Bell and Allen Newell were the first to provide enough detail to help designers in their great 1971 book, Computer Structures. Hennessy and Patterson in 1990 contributed their valuable Computer Architecture, whose Appendix E is very helpful. Blaauw and I added to the collection with Chapters 9–16 of Computer Architecture.
Beyond Collection
The next step after collection is careful, evenhanded criticism of particular exemplars. In computer design, we see this both in the books of collections and in journal reviews of particular machine descriptions.
Next beyond criticism comes analysis, comparing one exemplar against another, assessing the differences in light of the objectives of each. Analysts are tempted to criticize the selection of product goals, rather than the effectiveness of the designing meeting those goals. Such analysis doesn’t much help future designers.
A further step needs to follow comparative analysis. Some features of a design seem strong, others weak. Some approaches to design problems work; others do not. Hence careful analysts will derive from each example Rules of Good Practice to guide new syntheses. In most engineering disciplines, these rules are collected into handbooks, and ultimately into standards.
What about Software Design?
Computer design has progressed far through the sequence of collection, criticism, comparative analysis, and rules for synthesis. Software design is way behind.
Perhaps this is merely a question of youth. Software engineering as a discipline dates from 1968;7 computer engineering, from 1937.8 So far we have descriptions of individual exemplars of operating systems,9 collections for programming language descriptions and rationales,10 and little else.
Describing an operating system architecture is much more difficult than describing that of a computer. The functions are individually more complicated, and there are more of them. Moreover, the semantics of the operation Link are more difficult to describe than those of Divide. I believe we are dealing with two orders of magnitude more complexity. That will surely retard the collection, criticism, analysis, and synthesis of major software exemplars. I rejoice that Grady Booch has undertaken to assemble a Handbook of Software Architectures, currently as a Web site, ultimately for print.11
Who?
Systematizing exemplars for study is a task of scholarship, not of design. Scholars and designers are different in taste and temperament. Designers often drive on from the conclusion of one project to the initiation of another, without pausing for much reflection, much less works of scholarship. Only as a discipline matures does it attract scholars (or matured designers, ready to reflect).
How Encouraged?
Does modern engineering academia value and praise the work of the systematizer? Can one get tenure for doing such? In many institutions this work would be valued in a History of Science and Technology Department, but not in an Engineering Department.
Exemplars—Laziness, Originality, and Pride
Whoa! The above discussion on exemplars in design skips lightly by some issues very real for each designer:
• Isn’t copying an early design, a precedent, just an exercise in laziness? Can an honest professional do that with integrity?
• People become designers because they like to make things. What fun is there in confining one’s self-expression within the iron cage of another’s style?
• The world highly values originality and innovation and rewards them with respect, reputation, and sometimes fame and fortune.
• One’s special contribution to the human race depends upon one’s own unique vision. Isn’t it a disservice to neglect or suppress this originality?12
Some Perspective
Lest there be misunderstanding, I most emphatically do not assert that most design problems can be solved by adapting exemplars, nor do I advocate their slavish copying.
I do assert that
• The designer should know well the exemplars of his craft, their strengths, their weaknesses. Originality is no excuse for ignorance.
• In engineering, if not in the arts, gratuitous innovation (that is, not anticipated to be “better” in some useful sense) is a foolish idea and a selfish indulgence of pride—because of the unavoidable risk of unintended downside consequences.
• Designers who master the styles of their predecessors have more treasures upon which their originality can draw.
Laziness
Certainly the lazy or slack designer can minimize his work by picking an exemplar and just modifying it to fit. By and large, those who just copy do not draw on ancient or remote exemplars but only on those that are most current and fashionable. The world is full of lazy Bauhaus architecture and mediocre ranch-type homes done in Frank Lloyd Wright’s “prairie” style.
Not laziness, but a high level of enthusiasm and diligence is required for the mastery of the corpus of exemplars available in any design domain.
Originality and Pride
It seems to me that the current premium on design originality misleads. To paraphrase Vitruvius, whatever the medium, one wants a design that meets the functional need, is robust and durable under stress, and gives the user pleasure. So with Shaker furniture, with Revere’s tableware, with Peck and Stowe’s needle-nosed pliers.13
What then of originality? Well, it can certainly delight. We have all seen new designs so sparkling fresh that we rejoice at the elegance of the solution—a Leatherman folding pocket tool, a Slinky toy, a cable-stayed bridge.
But the delight lies in the superior elegance of the new solution to an old problem, not in its novelty per se. This is shown by the new delight each time we use the tool or toy. It does not fade. On the other hand, mere novelty is a cheat for satisfaction. The seven-day wonder grows old. As its novelty fades, so does the delight. The novelty seeker is perpetually driven. There is no resting delight.14
Originality as Goal or By-product
He who seeks originality is apt to find novelty, but not permanence of delight. On the other hand, he who seeks to make designs that really work is most apt to come up with new designs of enduring value, almost as a by-product.
Pride
Closely tied to the striving after originality is pride, a desire to make a name for oneself. This ancient cause and consequent of humanity’s fall infects all design, and ruins much.
Early on it manifested itself in the Tower of Babel. “Come, let us build a tower to heaven, and make a name for ourselves.”15
Shelley in one of his poems captures the ancient and modern desire: “My name is Ozymandias, King of Kings; Look on my works, ye Mighty, and despair.”
The desire to be original has degraded many a work.16
Notes and References
1. Howard [2006], Dr. Kimball and Mr. Jefferson.
2. Tovey [1950], “Johann Sebastian Bach” says, “Indeed, there is no branch of music, from Palestrina onwards, conceivably accessible in Bach’s time, of which we do not find specimens carefully copied in his own handwriting.”
3. Lehman [1976], “A model of large program development”; Parnas [1979], “Designing software for ease of extension and contraction.”
4. Wilkes [1985], Memoirs of a Computer Pioneer, 108–109.
5. Bell [1978], Computer Engineering: A DEC View of Hardware Systems Design.
6. Hoff [1972], “The one-chip CPU—computer or component?”; Patterson [1981], “RISC I”; Radin [1982], “The 801 minicomputer.”
7. Naur [1968], “Software engineering.”
8. Aiken [1937], “Proposed automatic calculating machine.”
9. Multics, UNIX, OS/360, Linux.
10. Sammet [1969], Programming Languages; Wexelblat [1981], History of Programming Languages; Bergin [1996], History of Programming Languages, vol. 2.
11. Booch [2009], “Handbook of software architecture.”
12. Wren’s St. Paul’s Cathedral shows that glory can be created within a tradition, as well as outside.
I find delight in Disney World’s exercises in working within styles and yet expressing wonderful originality. Consider Cinderella’s Castle, Tom Sawyer’s Island, the Haunted House, the Swiss Family Robinson’s Treehouse, and the 19th-century Main Street. In that context, even the exaggeration and parodying of styles is workable and can be delightful.
13. Heath [1989], “Lessons from Vitruvius,” is an excellent overview of Vitruvius. The assertion is that Vitruvius sets forth a design method, essentially a branching-tree approach, that leads one to choose among 45 house types. This is a major reference with respect to the use of exemplars and of simplified design methods.
14. I think this is a true test between godly pleasures and satanic counterfeits. For real pleasures give satisfaction (satis = “enough”). One gets enough food, enough sleep, enough work, enough play, enough lovemaking. The perverted, however, always seeks a new delicacy, a different taste, a progressive weirdness.
15. Genesis 11.
16. I work in such a building. By its context, Sitterson Hall could easily have perfected a visual quadrangle with the facing Carolina Inn. This is the same height, an elegant colonial building, and made of the same brick. “Originality” led in Sitterson to a different and ugly steel roof and to third-floor dormer windows that are too high for seated occupants to enjoy the view. And the coherent visual quadrangle is not realized.