Submitted to the OOPSLA-88 workshop on the Specification and Design for Object-Oriented Programming. Sept. 26, 1988
We believe the goals of software quality and productivity will be best served by the methodical cataloging of successful designs. We are as yet unable to prove this, nor are we able to cite many examples [see Cunn87 to appear in JOOP, for one example]. However, we remain inspired by the impressive design catalog assembled by Alexander [Alex77] in the architectural domain.
We have, for the last year, carefully read Alexander's own analysis of the design cataloging problem for architecture [Alex79], paying considerable attention to corresponding issues in software engineering. For example, Alexander strongly believes that only the future inhabitants of a structure (or people of very similar need) know or care enough to build a truly livable environment. In short, we have made a mistake in placing so much design responsibility in people trained only in architecture. Likewise, we suspect that designers trained only in computer programming will play an ever decreasing role in computer system design.
The fact that so many analogies can be found between architecture and software engineering is not too surprising. Both are activities conducted by similar sized teams (one to hundreds) over similar intervals (weeks to years). Alexander himself claimed solutions for the generalized design problem in a work whose importance he now minimizes [Alex64]. We have found dissimilarities between architecture (as viewed by Alexander) and software engineering an enlightening source of discussion too. For example, Alexander claims most good architectural ideas evolved out of uncountable generations of people building structures for their own need. These ideas, passed on from generation to generation, were subject to a form of natural selection. We believe that the same forces may be in practice for software engineering today, and believe that we can further the evolutionary effect by careful documentation.
We find much encouragement in Alexander's tactic for reintroducing selection into a field of design recently taken over by disinterested experts (i.e. architects in the last 100 years). A highly structured form of essay, called a written pattern, is substituted for bits of knowledge previously passed inadvertently between generations. Our goal is to borrow the form of written patterns for the encoding of similar software engineering knowledge, so that it might be efficiently introduced into fields where the domain knowledge held by practitioners would prove even harder to encode (into say, requirements documents or specifications) for the use of trained software engineers.
References
[Alex64] Alexander, Christopher, et al., Notes on the Synthesis of Form, Harvard University Press, Cambridge, MA (1964).
[Alex75] Alexander, Christopher, et al., The Oregon Experiment, Harvard University Press, Cambridge, MA (1975).
[Alex77] Alexander, Christopher, et al., A Pattern Language, Harvard University Press, Cambridge, MA (1977).
[Alex79] Alexander, Christopher, et al., The Timeless Way of Building, Harvard University Press, Cambridge, MA (1979).
[Beck87] Beck, Kent and Cunningham, Ward, "Using Pattern Languages for Object-Oriented Programs," Technical Report No. CR-87-43 (Sept. 1987).
[Cunn87] Cunningham, Ward and Beck, Kent, "Constructing Abstractions for Object-Oriented Applications," Technical Report No. CR-87-25 (March 1987).
[Mulf87] Mulfinger, Dale, "Putting a Pattern Language to Work," Fine Homebuilding(38), pp. 49-53 (Spring 1987).
[Roch88] Rochat, Roxanna, ed., "To Build a Pattern Language for Smalltalk Programs: Study Group Notes," Technical Report No. SPT-88-09 (Sept. 1988).
[Thal86] Thallon, Rob, and Edrington, David, "Working With a Pattern Language," Fine Homebuilding(36), pp. 51-55 (Dec. 1986/Jan. 1987).