Patterns Of Software
Richard P. Gabriel book, 1996, ISBN:0195121236
has the full text available free online as PDF EBook.
- the full plaintext is also available.
- notes concept of Habitable Software.
- includes his essay "Failure of Pattern Languages"
- The full text of Christopher Alexander's foreword is also elsewhere. Does all this thought, philosophy, help people to write better programs? For the instigators of this approach to programming too, as in architecture, I suppose a critical question is simply this: Do the people who write these programs, using alexander patterns, or any other methods, do they do better work? Are the programs better? Do they get better results, more efficiently, more speedily, more profoundly? Do people feel more alive (aliveness) when using them? Is what is accomplished by these programs, and by the people who run these programs and by the people who are affected by them, better, more elevated, more insightful, better by ordinary spiritual standards? cf Hero's Journey, Nature Of Order
Contents
- I. Patterns of Software
- Reuse Versus Compression
- Habitability and Piecemeal Growth
- Abstraction Descant
- The Quality Without a Name
- Pattern Languages
- The Failure of Pattern Languages
- The Bead Game, Rugs, and Beauty
- II. Languages
- Language Size
- The End of History and the Last Programming Language
- Productivity: Is There a Silver Bullet?
- III. What We Do
- What We Do
- Writing Broadside
- IV. Life of the Critic
- A Personal Narrative: Journey to Stanford
- A Personal Narrative: Stanford
- V. Into the Ground
- Into the Ground: Lisp
- Into the Ground: C++
- Money Through Innovation Reconsidered
- Epilogue
- References
Excerpts (partial)
Foreword by Christopher Alexander
A year or two ago, I was astonished to get several letters from different people in the computer science field, telling me that my name was a household word in the software engineering community: specifically in the field of object-oriented technology
In my life as an architect, I find that the single thing which inhibits young professionals, new students most severely, is their acceptance of standards that are too low. If I ask a student whether her design is as good as Chartres, she often smiles tolerantly at me as if to say, “Of course not, that isn’t what I am trying to do. . . . I could never do that.” Then, I express my disagreement, and tell her: “That standard must be our standard.
Can you write a program which has the enabling power of Dr. Johnson’s dictionary? Can you write a program which has the productive power of Watt’s steam engine? Can you write a program which overcomes the gulf between the technical culture of our civilization, and which inserts itself into our human life as deeply as Eliot’s poems of the wasteland or Virginia Woolf’s The Waves?
I must also be accurate about our success. This has come about in large part because, since 1983, our group has worked as architects and general contractors. Combining these two aspects of construction in a single o ffi ce, we have achieved what was impossible when one accepts the split between design and construction
If the heart of human existence, what matters most deeply to man, woman, child, really can find its way into computer programming, and into the programs, and into the meanings of those programs, and into the actual code and substance of those programs, and into their effects--then the future world will be changed immeasurably.
Preface
This book is broken into five parts: · Patterns of Software · Languages · What We Do · Life of the Critic · Into the Ground
“Into the Ground” is the story of the company I founded--from its birth in 1984 until its death in 1994. The lessons to be learned from this experience center on the fact that the company carried out its technical agenda perfectly yet it failed miserably
The Quality Without a Name
The first place where I think I differed with others’ interpretation of Alexander’s work was in defining the users or inhabitants of a piece of software as its coders and maintainers.
Now I am at the point of trying to figure out what corresponds to Alexander’s patterns. To do this, though, requires figuring out as precisely as I can what the quality without a name is in the realm of software
Alexander’s search, culminating in pattern languages, was to find an objective (rather than a subjective) meaning for beauty, for the aliveness that certain buildings, places, and human activities have. The objective meaning is the quality without a name, and I believe we cannot come to grips with Alexander in the software community unless we come to grips with this concept.
Alexander stated: I was no longer willing to start looking at any pattern unless it presented itself to me as having the capacity to connect up with some part of this quality [the quality without a name]. Unless a particular pattern actually was capable of generating the kind of life and spirit that we are now discussing, and that [sic] it had this quality itself, my tendency was to dismiss it, even though we explored many, many patterns.
Alexander says: It is a subtle kind of freedom from inner contradictions
This statement reflects the origins of his inquiry into the quality. It started in 1964 when he was doing a study for the Bay Area Rapid Transit (BART) system based on the work reported in Notes on the Synthesis of Form
Alexander was studying the system of forces surrounding a ticket booth, and he and his group had written down 390 requirements for what ought to be happening near it.
For example, if one person stopped and another also stopped to talk with the first, congestion could build up that would defeat the mechanisms designed to keep traffic flow smooth. Of course there was a requirement that there not be congestion, but there was nothing the designers could do to prevent this by means of a designed mechanism.
So it became clear that the free functioning of the system did not purely depend on meeting a set of requirements. It had to do, rather, with the system coming to terms with itself and being in balance with the forces that were generated internal to the system, not in accordance with some arbitrary set of requirements we stated
My whole analysis of requirements was certainly quite congruent with the operations research point of view that goals had to be stated and so on. What bothered me was that the correct analysis of the ticket booth could not be based purely on one’s goals, that there were realities emerging from the center of the system itself and that whether you succeeded or not had to do with whether you created a configuration that was stable with respect to these realities
Alexander proposes some words to describe the quality without a name, but even though he feels they point the reader in a direction that helps comprehension, these words ultimately confuse. The words are alive, whole, comfortable, free, exact, egoless, and eternal. I’ll go through all of them to try to explain the quality without a name
The quality which has no name includes these simpler sweeter qualities. But it is so ordinary as well that it somehow reminds us of the passing of our life. It is a slightly bitter quality. (Alexander 1979) This slightly bitter quality is at the center of Alexander’s pattern languages
What is revolutionary about Alexander is that he is resuming the quest for an understanding of objective quality that science and philosophy abandoned in the modern era. In the seventeenth and eighteenth centuries, a tension developed in which mind and matter were separated by science and philosophy
The study of beauty stopped because beauty became a mere contingency-whether something was beautiful didn’t depend much or at all on the thing, only on the thing as perceived by an unnecessary observer. A thing was beautiful to someone: It was not simply beautiful.
For many, Alexander is merely pining for the days when quaint villages and eccentric buildings were the norm. But face it, the buildings he hates, you hate too; and buildings he loves, you love. If this is true, then maybe there is an objective value that we all can recognize
there are programs we can look at and about which we say, “no way I’m maintaining that kluge.” And there are other programs about which we can say, “Wow, who wrote this!” So the quality without a name for software must exist.
If we look carefully at the buildings, towns, and cities that Alexander admires, we will see that they are European or perhaps even Third World. This suggests a couple of lines of inquiry into what the quality might be.
European building has an interesting constraint: There isn’t much space
Europe has a long history, and there are two more effects of that. One is that when people are put into a small space, building with flammable materials is dangerous. Therefore one must build with more durable and difficult materials. This implies that the standard of perfection must drop, and the results are buildings that look more like nature--more fractal-like.
Some of these things might be reasons to question whether the quality without a name really exists separate from the quality of looking like nature or the quality of being highly compressed.
I still can’t tell you what the quality is, but I can tell you some things about software that possesses it:
I wish we had a common body of programs with the quality, because then we could talk about them and understand. As it is, programs are secret and protected, so we rarely see any but those we write ourselves
Pattern Languages
There are few fields that blend art and science: Architecture is one, and computer science is another
Before we plunge into patterns, I want to set the stage for the accepted view of how architecture is done, at least in the pre-Alexander world
This view of architecture should be familiar to software theorists: It corresponds to the Waterfall Model with a Niagara-sized waterfall.
Enlightened folks nowadays tend to view askance this methodology, preferring one or another variant of the Spiral Model. (To be fair, the original Waterfall Model contains backward arrows linking later stages to earlier ones in a feedback type of arrangement, so there actually is not as sharp a contrast between the Waterfall and other models as some would have us believe.)
The first of Alexander’s contributions to architecture was to reject the separate architect and builder model and to posit user-centered design--in which users (inhabitants) design their own buildings--and the architect-builder who would blend the activities of design and construction
The mechanism he proposed to accomplish his new model was the pattern language
Of course, because usually several patterns can solve a given problem, and any pattern requires a particular context to be effective, the process is generally not
linear but is a sort of constraint-relaxation process. These days we know all about this sort of process, but back when Alexander came up with pattern languages, it was relatively new.
For Alexander, the variations of a pattern depend on the other patterns it contains and those containing it, thus eliminating the possibility of systematic variations. Patterns are not well structured enough to have systematic variations--their variations are too context dependent.
One thing that strikes many readers of the pattern language is the degree to which Alexander talks about people and their activities in the patterns--the patterns are a response to his arguments about how life is best lived
Let me present an example pattern--I’ll condense it quite a bit to save space. 179. Alcoves*
What’s interesting to me is the argument about how families are served by alcoves. This seems to go well with Alexander’s desire to emphasize that the quality without a name is concerned with life and living
Part of Alexander’s research program is to creative generative patterns-patterns that generate the quality without a name. Generativeness is an interesting trait. Typically something is said to be generative when it produces the generated quality indirectly.
Another example from a different domain is advice on how to hit a tennis ball. The advice I’m thinking of is that you should not concentrate on hitting the ball at the point of impact but, instead, on hitting a point beyond the ball in the direction the racket is moving
Such advice is generative: The goal is to hit smoothly and with full power, but this goal is not part of the advice. Rather, the advice is to do something else which has the side effect of achieving the goal.
Patterns in a pattern language are intended to be generative--they are supposed to generate the quality without a name. Just as the advice to write clearly and simply is not possible to follow--because writing clearly and simply is achieved by choosing words and syntax carefully, by choosing presentation order, and by deciding how to emphasize topics in sentences and paragraphs--neither is the advice to produce the quality without a name.
The Failure of Pattern Languages
I think the quality without a name is vital to software development, but I’m not yet sure how, because I am not clear on what the quality without a name is in the realm of software. It sits zen in the midst of a typhoon frenzy of activity in both architecture and software. Alexander’s story does not end with the publication of A Pattern Language in 1977. It went on and still goes on. And Alexander did not sit still after he wrote the patterns. Like any scientist he tried them out.
And they did not work.
...somewhat nice in plan, but it basically looks like any other building of this era. One might wonder why its plan is so nice, but in any really fundamental terms there is nothing to see there. There was hardly a trace of what I was looking for.
Alexander determined that they failed because the geometry of the buildings was not as diff erent from the standard modern geometry as it needed to be to generate the quality. One of his reactions was to consider the process of building: the mortgage process, the zoning process, the construction process, the process of money flowing through the system, the role of the architect, and the role of the builder. By controlling the process, you control the result, and if the control retains the old, broken process, the result will be the old, broken architecture.
This resonates with what we see in software development.
First he examined the process closely, identifying places where its details did not serve the quality without a name and geometry. Second, he performed several important experiments in which he controlled or nearly controlled the entire process. These experiments were based on an alternative process developed by Alexander, which he called the “grassroots housing process.”... families would be encouraged initially to build small homes. Because materials would be free and the only fees would be for square footage, each family would be encouraged to improve or embellish its existing space and the cluster’s common space. As time passed and the fees dropped in later years, homes could be enlarged. (incremental/iterative) (The families, by their own frequent testimony, love their houses.)
Not only must you decide to build the right thing, but you also must build it with skill and artistry. This leads to an obvious question: Are buildings with the quality without a name just too hard to put together deliberately, and were they created in older societies only by chance and survive only because of the quality? Or even more cynically, is there a form of nostalgia at work in which everything old is revered, because it comes from a more innocent and noble age? There is another, chilling possibility: Perhaps it takes a real artist to create buildings and towns possessing the quality without a name.
Another possibility: Alexander's judgment is wrong, his taste overly narrow?
This should not dissuade us from considering how to create things with the quality without a name.
But what of geometry? Alexander always goes back to this. And one of his key questions is: What dictates geometry possessing the quality without a name— what is that thing that is falsely called simplicity? What corresponds to geometry for us?
I think it is the code itself.
In 1995, software developers are writing and publishing patterns... When I look at software patterns and pattern languages, I don’t see the quality without a name in them, either.... My patterns are doggerel, just as are poems written quickly this way—four or five at a sitting.
But Alexander’s pattern language is not doggerel... It is clear that the patterns themselves have the quality without a name, and I think this is because Alexander and his colleagues are pattern artists. It just seems that the experiments that Alexander’s team did in Mexicali were not done by artists or that the muse didn’t visit them during the process.
The next chapter of his story takes him back to geometry and art. It’s probably a story that has only the most metaphorical application to software because it has to do with beads, beauty, art, geometry, and Turkish carpets.
The Bead Game, Rugs, and Beauty
“Bead game” refers to Hermann Hesse’s imaginary game in which all forms—art, science, nature—can be represented in a single way. (Glass Bead Game) "It is possible to invent a unifying concept of structure within which all the various concepts now current in art and science can be seen from a single point of view. …in our world, confused and fragmented by specialisation, the conjecture takes on special significance. …we need a bead game; and it is vital to ask whether or not a bead game can be invented."
Money Through Innovation Reconsidered
I would guess that fans of capitalism generally believe that innovation is the critical success factor and that natural evolution derived from competition makes the world better for consumers
The first problem is thinking that innovation means invention
But even in innovation there is a degree of improvement implied by “alter” or “make new,” which is the root meaning of the word. I’ll adopt the term radical innovation to mean an innovation based on new ideas rather than on incremental improvements to known ideas
The second problem is in thinking that innovation causes the world to greatly improve for consumers, as witnessed by Binstock’s comment, “when the fittest leap forward in their abilities
My thesis is simple: Invention, radical innovation, and great leaps forward do not produce revenue commensurate with the required effort in the software industry, and invention usually doesn’t work in any industry.
In 1990 I proposed a theory, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention (Gabriel 1990). Here are the characteristics of a worse-is-better software design for a new system, listed in order of importance.
Edited: | Tweet this! | Search Twitter for discussion