Pattern Languages of Program Design
Introduction by 
Ward Cunningham and 
Ralph Johnson

PLoP was founded to create a new literature.  That implies that the founders were somehow dissatisfied with the existing literature, which is true.  The founders, a handful of notables in the object-oriented programming community, had come to realize that the advance of their discipline was limited by a bias in its literature.  The bias, a product of the traditions of scientific publication, was to favor the new, the recent invention or discovery, over the ordinary, no matter how useful.  The founder’s interest in the ordinary may have come from their studies of software reuse. Or, it may have come from their observations that projects fail despite the latest technology for lack of ordinary solutions.  What matters is that all of the founders agreed to focus their attention on the dissemination of solutions.  The PLoP conference is one result.

This volume is the first of a series of books dedicated to the “Pattern Form”, our best guess at the way to share solutions.  We asked authors to submit papers in the “Pattern Form” without actually saying what that form was.  Christopher Alexander coined the term “Pattern Language” and explained the form well in his book “The Timeless Way of Building.”  Many authors were familiar with this work, and many more were introduced to it through a series of OOPSLA workshops and Internet discussion groups.  Even so, we felt authors needed considerable latitude in adapting Alexander’s form to the domain of computer programs.  The one thing we insisted upon was that each paper describe a solution, a thing that could be made to solve a problem.

You will notice as you read this volume that the solutions offered cover an incredible range of problems. This means that you will probably not find every chapter equally interesting.  We expect that as the PLoP community grows and matures that PLoP will itself splinter along traditional lines of interest.  Future volumes may not demand so much versatility of their readers.  For now we ask that you dig into all of the chapters. Even if you do not plan to apply what you read directly, it might inspire you with new ideas of how to present patterns, and it should certainly give you a perspective on why developing software is so hard.

For all this diversity in subject matter there were some surprising agreements among PLoP authors and attendees.  For one, most found that a solution, the essence of a pattern, could easily transcend the exact nature of it’s expression.  A pattern must ultimately reside in one’s own mind.  So, the various writing styles, from labeled sections of a standard template to running paragraphs of a more narrative style, have less to do with the success of a pattern than some more basic elements.  These include establishing a problem and its context, analyzing the forces bearing on the solution and, most important, offering a concrete solution.  Patterns that include these elements succeed.

A central feature of PLoP'94 was the writers workshops.  Instead of presenting their papers to an audience, writers listened to a small group discuss their paper and debate its strengths and weaknesses.
This gave authors a chance to learn how they were communicating, as well as learning alternatives to the techniques they were presenting.  We owe a great debt to Richard Gabriel for introducing us to the writers workshop in the spring of 1994.  Writers workshops were started a few decades ago in the creative writing community, and are an important way that new writers learn their craft and experienced writers polish their material. To the best of our knowledge, this is the first time it has been used in a technical community, but it seems to work well.

So that is the vision and process that has lead to this volume.  We are pleased with the result and are sure you will be also.  For us it is full speed ahead.  Every week we see some new piece of evidence that the shift of focus that we and our authors have made will have a profound and enduring effect on the way we write programs.  These chapters will hand you useful solutions.  They will also show by example the means for a revolution in our field.

Ward Cunningham, Program Chair
Ralph Johnson, Conference Chair

February, 1995



ward@c2.com