- Few Designs Are All-New
- The Roles of Exemplars
- What about Computer and Software Design?
- Studying Design Rationales of Exemplars
- What Should a Discipline Do to Improve Exemplar-Based Design?
- ExemplarsLaziness, Originality, and Pride
- Notes and References
This chapter is from the book
This chapter is from the book
This chapter is from the book
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;6 computer engineering, from 1937.7 So far we have descriptions of individual exemplars of operating systems,8 collections for programming language descriptions and rationales,9 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.10
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.