Introduction

In the early days of the software pattern discipline we were more interested in honing the art of writing good patterns than in understanding the fine points of pattern application. This sequence was a necessary casualty of the fact that our community had no initial body of pattern literature to build on. But, happily, the community has returned to this topic. There is an increasing number of papers on mining patterns, organizing patterns, and using patterns. There have even been whole conferences dedicated to the art of using patterns.

It's instructive to revisit Alexander's vision of how organizations should mine, administer, and use patterns. Even with the increased focus on these topics, most endeavors have missed the mark. It might be because Alexander's thoughts on these matters aren't presented until his third most popular work, The Oregon Experiment [Alexander+1975]; most readers don't make it past Pattern Language [Alexander+1977] and Timeless Way [Alexander1979].

Alexander's vision is that communities build pattern languages for themselves. Everyone carries their own pattern language within them; the goal is to find the common pattern language that makes a community a whole, that gives it the Quality Without a Name. How does a community build such a language? In this article, we look both at Alexander's ideals, and at how we've realized some of these ideals in our own pattern efforts.

What is a pattern?

Defining the term "pattern" seems a funny place to start in an article like this, but my reason for doing so will be clear immediately. The following comes from Chapter 4 of Oregon Experiment:

Let us begin with a brief definition of a pattern, remembering that from our present point of view, the essential feature which every pattern has, is that it forms the basis for a shared agreement in a community. Each one is, therefore, a statement of some general planning principle so formulated that its correctness, or incorrectness, can be supported by empirical evidence, discussed in public, and then, according to the outcome of these discussions, adopted, or not, by a planning board which speaks for the whole community.

With this in mind, we may define a pattern as any general planning principle, which states a clear problem that may occur repeatedly in the environment, states the range of contexts in which this problem will occur, and gives the general features required by all buildings or plans which solve this problem. In this sense, then, we may regard a pattern as an empirically grounded imperative, which states the preconditions for healthy individual and social life in a community. ([Alexander+1975], p. 101)

There are several important points worth extracting and emphasizing in this excerpt:

• A board exists to administer community consensus. Alexander envisions a planning board that accepts and rejects patterns according to whether they work. Though patterns represent a community consensus, there is an oversight board that functions as keeper of the patterns. That board nurtures the consensus process and ensures that the patterns are properly applied.

• A pattern is adopted on the basis of the empirical evidence supporting it. Patterns aren't just idealistic notions, but proven practices. For a new pattern to be admitted to an existing pattern language, it must be submitted to the same kind of empirical rigor befitting a scientific discovery.

• A pattern contributes to social and individual health. This pattern principle appears in print and comes up in talks once in a while, but most written patterns are bereft of social and humanistic benefits. Striving for human comfort isn't as arbitrary as it might first sound. All software is written to provide comfort for some person somewhere. If a given software practice doesn't contribute to human comfort, then it should probably should be viewed with some suspicion.

• "A pattern defines a field of spatial relations" says Alexander in The Timeless Way of Building, [Alexander1979] p. 267. A pattern is not about process, or a piece of legislation that directs behavior, or a simple rule of action. It is something structural, something usually made of matter, that carves out space. And this is not an isolated quote; this column explored the geometric issue thoroughly in previous installments [Coplien1998, Coplien1999a].

• "It is, indeed, the structure of the network which makes sense of individual patterns, because it anchors them, and helps make them complete...", from The Timeless Way of Building, page 312 [Alexander1979]. Patterns make sense only as elements of a pattern language. The goal of a community isn't just to collect individual patterns that solve interesting problems, but always to work at the level of the whole. It isn't an issue of collecting patterns; it's an issue of maintaining a pattern language.

The pattern board

Alexander's early work on A Pattern Language and The Timeless Way of Building led to a concrete vision of a building program for a college campus. These ideas took shape in a book, The Oregon Experiment in 1971 (though the book was not published until 1975). The ideas in the book formed the foundation of a program at the University of Oregon to guide piecemeal repair processes on campus, and to engage students and faculty in the evolution of their environment. The program succeeded in some degree; a post-evaluation study in 1977 cited the participatory nature of the pattern language and offered hope that it supported a new "tradition" of building [Grabow1983, 105]

Alexander envisions a planning staff that maintains the pattern language, with a board at its core. The staff handles administrative issues and tends to local patterns, while the board approves the patterns that are common to the community, which have global impact on the community, or which are necessary to support the local projects spawned by local patterns.

The following excerpts (in italics) are from Oregon Experiment. They serve as thought-provoking guides for software pattern programs. They often reflect what we have actually done in some of our own pattern programs.

(i) The community shall not adopt any form of physical master plan, but shall instead adopt the process which this book describes. [Alexander+1975], p. 27

A pattern language does not appear from thin air as a completed work, but is itself the product of an ongoing process of discovery and repair. Change is inevitable. Our understanding of a given domain evolves with time. We are still adding basic patterns to switching architecture pattern languages; the domain is broad, and it simply takes time to cover the space.

Domains themselves evolve with changes in technology and market. For example, the C++ Idioms pattern language [Coplien1999a] changed with the introduction of RTTI. We continue to research organizational patterns and refine the contexts in which they hold.

(ii) The most basic fact of this process is that it enables the community to draw its order, not from a fixed map of the future, but from a communal pattern language. [Alexander+1975], p. 27

Community involvement is a key principle of Alexander's pattern vision. It's important to draw in the community at all levels: in mining the patterns, organizing the patterns, and using them. Contrast this with projects run by architects as master planners--a worrisome approach both in construction and programming.

We tap the community and draw on its knowledge through pattern-writing workshops. One purpose served by these workshops is to help enculturate the community in pattern practice. But another agenda of these courses is to tap the student's knowledge, to give them an opportunity to write potentially key patterns in the supportive setting of a classroom environment.

We also have periodic Writers' Workshop [Coplien1997] lunches, usually run by Bob Hanmer. These can be a source of new patterns over time. One of the main benefits of these forums to date has been to refine the expression and technical content of patterns that were mined earlier.

(iii) The process shall be administered, on behalf of the community, by a single planning board of less than ten members, made up of users and administrators in about equal numbers, and a director of planning. [Alexander+1975], p. 29

We have what might be the equivalent of Alexander's director of planning: a single steward of the telecom patterns. The steward is an architect in the business unit served by the patterns. I, as a researcher, originally helped populate the pattern language and until recently helped with administration and housekeeping, but as patterns increasingly became a legitimate part of the steward's job, I was able to transition all of that work to him. We do not have a standing board, though there is an ad hoc community that serves some of the same functions as the board.

(i) The planning staff shall modify the published pattern language by deleting and inserting patterns to meet local needs. [Alexander+1975], p.137

There were three kinds of patterns in the Oregon experiment project. Even before the project started, Alexander had gathered 37 patterns relevant to a university setting, inspired largely by Cambridge. To those, the board added 18 patterns uniquely suited to a university setting. The rest of the patterns were developed by "users" for individual projects.

In the switching architecture projects, we're still trying to work our way toward the collection of the equivalent of the 37 patterns that seeded the Oregon experiment. What are the patterns that should seed any high-availability switching project? We know a small number of the patterns on this hypothetical list, since they come up again and again in such systems: LEAKY BUCKET COUNTER, RIDING OVER TRANSIENTS; these are low-level, "construction" patterns. The higher level patterns are harder to come by. We have a candidate set based on a small number of projects: BROADCAST PUMP (pumping several identical remote processors in parallel); SMART HASHING ON PUMP (running hashsums to prevent re-pumping large sections of memory that are still intact from the previous pump); SYSTEM INTEGRITY MONITORING (process scheduling is based on system integrity monitoring as a first principle, not as an add-on); and ISOLATE COMMUNICATIONS (a way for a processor to protect itself if another processor is "babbling" at it, or otherwise appears ill-behaved at the opposite end of a communication link).

To these, individual projects might add their own patterns depending on product characteristics: centralized or distributed processing, toll switching or local switching or private branch exchange; custom hardware or off-the-shelf hardware, etc. And, to these, individual programming teams or programmers may add their own patterns--some of which may mature over time (through Writers' Workshops [Coplien1997]) to join the set of broader patterns.

At the other end of the spectrum, telecom practitioners from several companies are working together to identify common patterns and to build one or more pattern language based on their shared experiences. This takes place in activities called "TelePLoPs" which are usually collocated with conferences such as ChiliPLoP and OOPSLA.

(ii) Those patterns which have global impact on the community, shall be adopted formally by the planning board, on behalf of the community. [Alexander+1975], p.139

There are ready opportunities for experienced designers to modulate and add to our pattern language. Most, but not all, of these patterns come from people with highly respected experience in the relevant domains. Some of these patterns have been mined in active pattern-mining activities run by researchers and architects, while others are individual contributions.

(ii)The collection of formally adopted patterns shall be reviewed annually at public hearings, where any member of the community can introduce new patterns, or change old ones. [Alexander+1975], p. 139

We have two major ways of incorporating new patterns into the switching pattern language. One is through occasional Writers' Workshops [Coplien1997] run as brown bag lunches. This has fostered a small community of people who support each other in writing and reviewing patterns to develop raw material for the pattern language.

The organizational pattern effort, like other pattern efforts in the industry (telecommunications patterns, pedagogical patterns, and many others) builds on workshops held at conferences like the PLoP conferences and OOPSLA. There were "Hot Topics" (workshops) for both telecommunications patterns and organizational patterns at ChiliPLoP this year, and both efforts will continue at OOPSLA in Denver in November.

(iv) The board shall only accept new patterns, or revisions of old patterns, on the basis of explicitly stated observations and experiments. [Alexander+1975], p.141

In our switching pattern culture, this almost goes without saying. We look either for broad substantiation of a pattern across several projects, or we hold the pattern up to the test of time. Ideas that have held for several decades, and sometimes several generations, are worthy of pattern status even if they exist only in a single culture.

Epilogue

Of course, the best laid plans of mice and men often go astray. In Oregon Experiment, Alexander had a major falling out with the Oregon architecture school dean. The dean took the Oregon Experiment draft too literally, a problem that was exacerbated by the inclusion of a real architect in the proposal, an architect whose job it was to do the "real" work after the users had completed their design. [Grabow1983, p. 177] If you look at Alexander's earlier works like Timeless Way, it is clear that he originally intended that such projects go forward without the intervention of a professional architect. "[T]here is no way the living town can be built by professionals" [Alexander1979], p. 354. And:

There is a strange dichotomy between the present architecture and planning professions. On the one hand, the architects are in the habit of creating completely mad idealistic utopias. These utopias often have little meaning, they are unlikely to be implemented; often no one in his right mind would want to implement them. They are personal dreams, not anchored in reality. Archigram's city on legs is an extreme example. [Alexander1969]

The architect was formally added to the Oregon experiment as a concession to the AIA (American Institute of Architects, a professional body), which was fearful of Alexander's plans. Alexander's rationalization--perhaps his hope--was that it wasn't the architects per se who were at fault, but the process the architects brought with them. [Grabow1983, p. 177]

And Alexander's attempt to apply the learnings of the Oregon experiment in Berekley between 1972 and 1974 didn't go much better. The Center for Environmental Structure -- run by Alexander -- was able to secure a spot on the city's ballot for a referendum that would start a two-year moratorium on municipal construction until a participatory planning process had been put in place. The process would be modeled after the Oregon experiment. The referendum passed, and an 18-member commission was appointed. There were also two staff members. But the two staff members took over and manipulated the commission to see their ends through: effectively, to complete a master plan. The commission ultimately decided not to adopt the proposal. [Grabow1983, ff. 157]

A successful pattern program depends on many factors, some of which may seem almost whimsical or incidental. So far, many of our projects have fared better than Alexander's. Good management support, a foothold for valuing experience, time for pattern mining and peer support for a pattern program are all important.

References

[Alexander1969]

Alexander, Christopher. Major changes in environmental form required by social and psychological demands. Ekistics, volume 48, 1969, pp. 78-85.

[Alexander+1977]

Alexander, Christopher. A Pattern Language. New York: Oxford University Press, ©1977.

[Alexander1979]

Alexander, Christopher. The Timeless Way of Building. New York: Oxford University Press, ©1979.

[Alexander1975]

Alexander, Christopher, et al. The Oregon Experiment. New York: Oxford University Press, ©1975.

[Coplien1997]

Coplien, James. The Column Without a Name: Writers' Workshops. C++ Report 9(4), April 1997, 51-60.

[Coplien1998]

Coplien, James. The Column Without a Name: Space, the Geometry of C++ Objects. C++ Report 10(9), October 1998, 40-44.

[Coplien1999a]

Coplien, James. The Column Without a Name: More on the Geometry of C++ Objects: Part 2. C++ Report 11(3), March 1999, 52-58.

[Grabow1983]

Grabow, Stephen. Christopher Alexander: The Search for a New Paradigm in Architecture. London: Oriel Press, 1983.

Generated with Harlequin WebMaker