The Introduction to Pattern Languages of Program Design 3 edited by Robert Martin, Dirk Riehle, and Frank Buschmann Addison-Wesley Longman, 1998
We hope, of course, that many of the people who
read, and use this language, will try to improve these
patterns -- will put their energy to work, in
the task of finding more true, more profound invariants -- and
we hope that gradually these more true patterns,
which are slowly discovered, as time goes on, will enter a
common language, which all of us can share."
Christopher Alexander et al. A Pattern Language, xv.
[Alexander et al. 1977]What’s new here is that there’s nothing new here.
Patterns are about what works. Patterns give us a way to talk about what works.
Stewart Brand, in his book How Buildings Learn, [Brand 1994] recounts an oft-told (and perhaps apocryphal) tale of a brilliant, but lazy college planner who built a new campus with no sidewalks at all. She waited for the first winter and photographed where people made paths in the snow between the buildings. The next spring, she put the pavement there. Patterns have this sort of quality. Instead of making brash, premature, and probably erroneous conjectures about what might work, pattern writers look for footprints in the snow, and describe what has worked already.
Talking about what works seems so obvious. Why hasn’t this happened before? Why is it happening now?
In the academic world, there is a relentless focus on the new. Academics are veritable novelty vampires, who consume new ideas rapaciously. This phenomenon is particularly acute in computer science, where four-month old technology can be deemed "traditional". Patterns, on the other hand, are dispatches from the trenches about what works. They are about recurring solutions, and if a lot of people have been doing something for a long time, it can’t be new, can it?
Because patterns are drawn from experience, they are not about invention or creation per se. Pattern writers don’t play God, and create the universe in their image, but they do play Adam and Eve, by choosing names for the denizens of their garden. This is a responsibility that is not to be taken lightly.
Ralph Johnson has pointed out that it is common in other academic disciplines to study subject matter that the researchers did not themselves create. Entomologists collect butterflies and categorize them, and talk about these categories, and why they exist. However, biologists do not create new forms of life (at least, not yet). Still, biologists can gather specimens, make observations, and discover categories without having to worry about being accused of plagiarizing nature. Similarly, pattern writers can play not only Adam and Eve, but Carolus Linnaeus as well.
Computer science is a young discipline that has for too long seen itself as a stepchild of mathematics and electrical engineering. While computer scientists spent their first generation trying to behave like mathematicians and physicists, they too often ignored the rich vein of indigenous subject matter that ran directly under their feet: the experience that can be gleaned from real programmers and real systems. It is a sign of new maturity and self-reliance that we can now borrow from architecture, biology, literature, communications, and, at last, even ourselves.
The patterns movement is in tune with a distintly '90s cultural Zeitgeist. It is a second-generation phenomenon, like Java. It’s about innovation in an age of sampling. Sampling has become a way of life on the World Wide Web. Popular musicians in the '90s often borrow shamelessly from their predecessors, not by merely quoting their phrases, but by using digital samplers to directly embed snippets of other people’s actual performances into their own work. Their artistic predecessors had broken every rule of harmony and composition as they strove unrelentingly for originality. Now, this exploration of increasingly inhospitable new frontiers is over. Musicians in the '90s solved their originality problem by ignoring it. Instead, they built on the past by combining existing elements of their artistic heritage in new ways.
From the beginning, one of the things that has distinguished the patterns community has been its aggressive disregard for originality. A good sign that something new is happening is when people say that new music, poetry, or art isn’t really music, poetry, or art at all. People argue as to whether patterns are really computer science, or even research. If what we are doing isn’t computer science, it ought to be.
While academia may be addicted to change, industry, on the other hand, certainly has no problem with things that are tested and proven. It does have a problem with talking about them. Why indeed should people in industry give their architectural insights away to their competitors? Why give away the store? What is gained by paying people to write patterns instead of programs? These are legitimate concerns. We certainly don’t expect PLoP to become a trade secrets show-and-tell conference.
PLoP USA is held at Allerton House, a turn-of-the-century manor surrounded by statues and formal gardens, set on a wooded estate on the banks of the Sangamon River, in rural Illinois. Pattern pilgrims travel through forty miles of corn and soybeans to reach Robert Allerton’s monument to architectural eccentricity. In making this journey, through some of the richest farmland in the world, the term "hybrid vigor" somehow comes to mind.
PLoP draws people and patterns from what must seem, on the surface, like an unworkably diverse pool. PLoP draws academics and practitioners, managers and programmers, consultants and students, and even the odd building contractor. Why the smorgasbord? Why is the patterns community so eclectic? Maybe it’s because there really are underlying architectural principles beneath seemingly disparate areas. Maybe there really are good ideas that scale, generalize, and travel well.
Nature invented cross-pollination to propagate successful innovations throughout a population rapidly. Farmers and horticulturists later learned that they could manipulate this process to create hybrids in order to counteract inbreeding and enhance characteristics they found desirable. The introduction of new genetic material from distant relatives frequently produced exceptionally productive and robust new varieties, hence the term "hybrid vigor".
Perhaps a caching scheme I heard about in a pattern culled from an application that looks nothing like the ones I write will, when examined in the proper light, be just what I need in one of my programs six months from now. This potential for hybridization is one reason why industry should be interested in patterns. The cross-pollination among the unique cross-section of industry and academia at PLoP allows best-practices to be quickly and widely disseminated, thereby bringing a healthy touch of hybrid vigor to all involved. So patterns people can play not only Adam and Eve, and Carolus Linnaeus, but Luther Burbank as well. Industry has more to gain than to fear from a real engineering handbook for software architecture.
That which a culture glorifies will flourish. Unfortunately, software architecture is often hidden. The patterns community provides software architects with something they have never had before: an audience.
Software architecture is often an afterthought. We reward results, even if they are the result of slash-and-burn engineering, and result in sprawling, shantytown architectures. For too long, software architects have toiled like the medieval artisans who carefully carved the backs of their gargoyles, knowing that high above the ground, their artistry could be seen only by God. Now that we have a forum where practitioners, and theorists, and programmers, and professors can get together to laud that which has worked, the architectural as well as aesthetic achievements of heretofore anonymous software designers can start to get some belated and well-deserved (mortal) recognition.
Languages, libraries, and frameworks are the medium in which software architecture is ultimately expressed. Patterns tell us how other architects have successfully put these pieces together. By drawing attention to recurring problems, patterns can drive the evolution of our tools, processes, languages, and frameworks, so as to allow reusable artifacts to address these problems directly. We can then use these off-the-shelf, and focus our design energy on ever loftier architectural concerns.
A system might have a good architecture or a bad architecture, but it can’t have no architecture at all. Whether by encouraging the infrastructure for wide-scale reuse, or the emergence of the components that underlie the latest rapid prototyping environment, architecture is the key to the division of labor that characterizes mature engineering disciplines.
Reuse is an act of trust. The pioneer who blazes a trail knows if he or she turned left to avoid a two hundred-mile detour, or to avoid a fallen branch. Those who follow do not have the benefit of this insight. They know only that to continue to follow the trail, they must turn left. Architecture needs to be about ideas that can stand on their own. Designers need a vocabulary that conveys meaning without requiring an encyclopedic, white-box knowledge of each and every abstraction of everyone who uses it.
Thomas Malthus was a 19th century clergyman and economist who grimly hypothesized that successful communities would grow until their needs exceeded the resources available to sustain them. Dr. Malthus came to Allerton Park in 1996. We received over 70 submissions, and nearly 110 registrations. Our infrastructure was bursting at the seams. Our submissions were more eclectic than ever. It seems inevitable that these forces will cleave our diamond-in-the-rough along its natural fissures. Indeed, these facets are already emerging. EuroPLoP, TelePLoP, ChiliPLoP, and UP, have joined good ol’ PLoP Classic USA. New books about patterns are sprouting like high-yield hybrids in the hot summer sun. The success of patterns has even turned them into a lightning rod for new academic research.
Powerful forces have been set into motion--have set us into motion. It’s fascinating to contrast a design conversation today with one we might have had a few years ago. For instance, not only are the once abstruse architectural notions presented in the Gang of Four book [Gamma et al. 1995] common knowledge, but they can be proposed, compared, and dismissed with one simple name. They are becoming part of a design lexicon that may well be with us for generations. The power and conciseness that this new vocabulary gives its speakers is striking. We are still a long way from having the sort of pattern language for software architecture that Alexander attempted for building. Still, three years ago, few of us really had any idea where all of this might be headed. It’s hard now not to think that we are witnessing something important and enduring.
Just under a century ago, two brothers could build an airplane in a bicycle shop. Just a generation later, the engineering expertise that went into a pre-World War II warplane dwarfed any of the individuals engaged in its design. The pioneers had been supplanted by teams of superbly skilled, highly specialized collaborators who together defined the architectural lexicon and division-of-labor that allowed them to partition their work and integrate it into a working whole. They were able to divide up their work because they could discern the distinct, emerging architectural elements in their engineering domain, and the boundaries between them. Small groups of skilled designers can still juggle the pieces, but these pieces are cast at a much higher level.
In many ways, software architecture is just leaving its bicycle shop era. Brad Cox [Cox 1995] has observed, for instance, that "unlike the hardware industry, which has organized itself into a fully elaborated rainforest of mutually interdependent structures of production trees, the software industry remains stuck in the unicellular, bacterial stage of the primordial ooze."
Today, interstate highways run over the tracks left by the wheels where westbound wagon trains once rolled. The pioneers could never have conceived of the engineering effort necessary to build the spectacular bridges and tunnels we have built, nor of the machinery to move mountains of stone, concrete, and asphalt that would dwarf the pyramids. We can make their journey of months in a matter of hours or days. Yet, we did this not by blazing new trails of our own, but by looking for footprints in the snow, and putting the pavement there.
Brian Foote, Urbana, Illinois
[Alexander et al. 1977] Christopher Alexander, Sara Ishikawa, and Murray Silverstein A Pattern Language Oxford University Press, Oxford, UK, 1977 [Brand 1994] Stewart Brand How Buildings Learn: What Happens After They're Built Viking Press, New York, NY, 1994 [Cox 1995] Brad Cox No Silver Bullet Revisited American Programmer Journal November, 1995 [Gamma et al. 1995] Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Longman, Reading, MA, 1995