I understand that the software patterns, insofar as they refer to objects and programs, and so on, can make a program better. That isn't the same thing, because in that sentence `better' could mean merely technically efficient, not actually `good.' Again, if I'm translating from my experience, I would ask that the use of pattern language in software has the tendency to make the program or the thing that is being created morally profound--actually has the capacity to play a more significant role in human life. A deeper role in human life. Will it actually make human life better as a result of its injection into a software system? ... So I have no idea whether the search for something that helps human life is a formal part of what you are searching for. Or are you primarily searching for--what should I call it--good technical performance? This seems to be a very, very vital issue. [Alexander1999]

Thus we are challenged and called to account by the person usually cited as the inspiration for software patterns. In the previous column, I took a broad historic look at how software history and patterns in particular had taken shape over the years in response to the tension between mechanization and art. In this column, I'll bring the same dichotomy much closer to home, comparing Alexander's aspirations for patterns with typical citations from contemporary practice.

A note in advance: I know that there is a wide spectrum of pattern practice out there, and it's difficult to characterize any single perspective as typical. As such, this column might be viewed as a collection of caricatures. I believe it is not; my experiences dealing with people working on patterns tends to bear out trends evidenced in the following comparisons. But, no matter; even if you don't find yourself in these camps, the fact that such camps exist should be thought-provoking.

And another note in advance: In this article, I will be raising some hard questions about the work of our community as it has rolled out in the work of individuals. Many of these people are long-standing good friends. And most of them mean well; more than that, many of them are trying to meet some need somewhere, according to some value system. My goal here is to point out the stark incongruity in value systems between the computer-science-oriented pattern community and what Alexander intended.

Let's start with something simple: pattern format. Why do we have pattern form? Let's start with this answer from Alexander:

There are two essential purposes behind this format. First, to present each pattern connected to other patterns, so that you grasp the collection of all 253 patterns as a whole, as a language... Second, to present the problem and solution of each pattern in such a way that you can judge it for yourself... [Alexander1977] , p.11

along with this insight on how patterns are to be used together.

Each pattern then, depends both on the smaller patterns it contains, and on the larger patterns within which it is contained...

...

And it is the network of these connections between patterns which creates the language...

...

In this network, the links between the patterns are almost as much a part of the language as the patterns themselves...

...

It is, indeed, the structure of the network which makes sense of individual patterns, because it anchors them, and helps make them complete... -- [Alexander1979] , ff. 312

Pattern form exists, first and foremost, to support the building of pattern languages--that's almost an exact transliteration of the above quote. Compare that perspective with this all too typical posting from the pattern discussion group by Rolf Katzenberger, November 1998:

IMHO patterns have value in isolation, too. I have often wondered why the focus is mostly on a final pattern language, while it takes so much time and so many contributors to polish it.

Rolf might be right that these patterns have some value in isolation, though such value is much less than what we'd get from the language in which these patterns are embedded. But it still begs the question of how much use we can even make of individual patterns that aren't anchored in a language; Alexander tells us that they can't be made complete and that they are, literally, nonsense. And beyond that, Rolf's quote gives a hint of instant gratification. Alexander knew that it took hard work to mine these patterns, to build a language, and that it takes years. Why does it take so much time to polish these patterns? Because the problems are hard, and because communication is hard. Yet we are in an industry where long-term investment seldom happens, and that's because we can't prove that the investment will pay off, and that's because we insist on reductionist models of the world based on cause and effect. Most of what we do is too complex to be captured in cause-and-effect models. That's a first principle of the generative process of pattern application, but it's a perspective lost on our industry. It's a bad match for the value system.

I shouldn't be hard on Rolf; he's trying to point out the advantages we have achieved. Things are so bad in software design that even individual design solutions called patterns, even those such as the GOF structures [Gamma+1996] , actually make things better. But we have so far to go. We haven't yet gone beyond local considerations to considerations of system structure. And even when thinking of system structure, it's rare that we think of wholeness. And when we think of wholeness, we again try to do so in terms of reduction to parts. Computer science is deeply steeped in western reductionism, and it will be a lot of work and a long time before we get out. We should pretend neither that we've achieved this with patterns -- in their current state of practice -- nor that it will be easy.

One thing that makes it harder is that the good drives out the perfect, and GOF patterns are just good enough to do that. The earliest literature was the GOF literature, and it is still probably the most broadly disseminated and broadly cited of all pattern collections. As such, the work has perhaps unwittingly done the industry a great disservice. The contents of that book actually are useful. It's just that it's hard for anyone using them to see that they are patterns in the sense that Alexander uses the word. I for one don't think they are, though maybe they could be with some hard work; that was the subject of the work I've been taking to the most recent PLoP conferences for review [Coplien2000] . The fact that the GOF structures are called patterns, and that they claim the Alexandrian legacy, clouds the issue for any modern software practitioner looking for good examples of pattern literature worthy of emulation.

One of the reasons that patterns are hard is that, contrary to popular wisdom, they're more about feeling than about fact. I'm sure that statement shocks many of you. It's another place that most practice falls short of the mark. This is clear in the pattern mechanization movement, where patterns are reified as objects or formalized in notations or formal language. Again, note this from Alexander:

One test says that a pattern is alive if its individual statements are empirically true.

context -> conflicting forces -> configuration

So we say that a pattern is good, whenever we can show that it meets the following two empirical conditions:

1. The problem is real...

2. The configuration solves the problem...

...

A pattern only works, fully, when it deals with all the forces that are actually present in the situation... The difficulty is that we have no reliable way of knowing just exactly what the forces in a situation are... To do this, we must rely on feelings more than intellect. -- [Alexander1979] , 282 - 283

Compare that with the growing body of pattern literature from academia that looks like Figure 1. Not much feeling there. I'm not sure there's a lot of intellect, either, but I think most people would feel that there is. It's what our community values.

---

Operator  Design Pattern Adapter
   Objective    Modify the interface of an object
   Parameters   Objects: ADAPTEE, TARGET;
   Subtasks   
         1 - Specify Adaptation Object: ADAPTEE, TARGET -> ADAPTER
           1.1 - Create Object: -> ADAPTER
           1.2 - Compose/Inherit Objects: ADAPTEE, ADAPTER -> ADAPTER
           1.3 - Inherit Objects: TARGET, ADAPTER -> ADAPTER
           1.4 - Specify Links: ADAPTEE, ADAPTER -> ADAPTER
   Consequences   
         ADAPTER will contain most of ADAPTEE functionality
         available through the TARGET object interface
   Product Text

         ADV/ADO ADAPTER
            Declarations
               ...
               Nested ADVs/ADOs
                  Compose ADAPTEE;
                  Inherit TARGET;
            ...
            Dynamic Properties

               Interconnection
                  With ADV/ADO ADAPTEE
                     TargetActions --> AdapteeActions;
         End ADAPTER
End Operator

Figure 1: An Abstract data View (A Formal Specification) for a Design Pattern
http://csg.uwaterloo.ca/patterns.html

---

The processes are much different, too. Compare:

Design is often thought of as a process of synthesis, a process of putting together things, a process of combination.

According to this view, a whole is created by putting together parts. The parts come first: and the form of the whole comes second.

But it is impossible to form anything which has the character of nature by adding preformed parts.

When parts are modular and made before the whole, by definition then, they are identical, and it is impossible for every part to be unique, according to its position in the whole. -- [Alexander1979] , p. 368

with this from pattern notable John Vlissides and his colleagues regarding their pattern work:

The tool ... lends itself to implementation with off-the-shelf components... [Budinsky+1996]

And finally, there's the moral component. Again, compare Alexander's

I would ask that the use of pattern language in software has the tendency to make the program or the thing that is being created morally profound--actually has the capacity to play a more significant role in human life. A deeper role in human life. Will it actually make human life better as a result of its injection into a software system?

from above, with the following press release that was distributed to the pattern mailing list by Doug Schmidt last year. This work is in part an outgrowth of Schmidt's highly publicized work that bears the pattern label.

The demonstration scenario entailed a pilot-commanded simulated fault of processor #2, performed in the midst of a bombing dive, seconds before weapon release. In both bombing runs of this nature, the pilot, USMC Maj. Gary Munroe, reported a smooth transition between computers ... as the fault was inserted. Both Mk76 practice bombs hit the target. This means that the ORB recognized the loss of processor # 2 and shifted all processing to #1 within a single 20 Hz frame, with no loss of data or performance. This was the first flight test of this real-time ORB, and constitutes an important step toward adopting ORB technology to systems with hard real-time constraints.

-- Air Force press release for system using University of Washington real-time ORB, based in part on the pattern work that was done there [Schmidt1999]

Do the TAO patterns cause software to play a deeper role in human life? It's a matter of one's value system. Again, it's a matter of comparing what Alexander was trying to do with what we are doing in his name.