Process Anda Thing

"The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing."

-- ChristopherAlexander, TheTimelessWayOfBuilding, p.247.

Also, p.255, ff.

"Now try to discover some property which is common to all the ones which feel good, and missing from all the ones which don't feel good. (...) This property will be a highly complex relationship. (...) the pattern is an attempt to discover some invariant feature, which distinguishes good places from bad places with respect to some particular system of forces. (...) one you discover a fluid field of relationships like this, you must redefine it, as an entity, to make it operational. (...) We must make each pattern a thing so that the human mind can use it easily and so that it may take its part among the other patterns of our patterns languages. For the same reason you must be able to draw it. If you can't draw a diagram of it, it isn't a pattern. ... A pattern defines a field of spatial relations, and it must therefore always be possible to draw a diagram for every pattern."

Sure, a pattern is both a ProcessAndaThing. However, Alexander was wrong when he said that if you can't draw a diagram of it, it isn't a pattern. Rather, the statement is meaningless.

Consider the diagram of Self-Governing Workshops and Offices in ApatternLanguage?. It is a good example of a pointless diagram that does not really illustrate the pattern. The picture on page 398 illustrates the pattern much better. Alexander often draws pictures that do not communicate, and I think he does it because he decided that every pattern should have a diagram.

If you try hard enough, you can draw a picture of anything. Love? Draw a heart. Peace? Draw a meadow with a stream through it, or a picture of Begin and Sadat shaking hands. These are no worse than Alexander's diagram for Self-Governing Workshops and Offices. The question is not whether you can draw a diagram, it is whether you can draw a diagram that helps people learn the pattern. If you have to know the pattern to interpret the diagram, the diagram doesn't help. The diagram needs to be more than just a symbol that represents the pattern.

In fact, Alexander was wrong when he said you need a diagram to make something be a pattern. What he should have said is that you need an example to communicate a pattern. If it is pattern, there should be lots of examples. However, most examples don't communicate a pattern very well. There are too many extraneous details. But a good example cuts through to the heart of the pattern. Sometimes Alexander communicates his examples though a picture, sometimes through a story, and sometimes through a diagram. Most patterns of buildings can be communicated through diagrams, but not all, and there are a lot of software patterns that are just as easily described with code as with diagrams. OMT or UML just describes a piece of most of the patterns in DesignPatterns.

I always remember that Alexander's work covered recurring themes in architecture, not software design. Here are some forces I see that make it hard for us to equate software patterns with architecture patterns:

It is not a primal requirement for survival. Organization of regions, towns, neighborhoods, buildings, and gardens -- and either feeling more alive or more dead in them -- is based on one of the primal requirements of human survival: shelter. We've been living in shelters since the beginning of mankind. Software systems are not a primal requirement for human survival (yet).
They are less timeless. Alexander's pattern language has themes that have been shown to be timeless over thousands of years. Software is very new compared to our work with shelters.
Relationships are logical, not physical. It's easier for people to understand why Alexander's pattern language is structured the way it is because not only does each pattern physically contain lower-level patterns, but we can easily discern the spacial relationships between them. It's not so easy with software. The essence of patterns in a beautiful system is intrinsic to its physical constructs (hardware & networking) and very logical in its structure and behavior.
The essence is intrinsic. If I see the picture in SouthFacingOutdoors it's easy to get the pattern's essence. If I look at a picture of a machine room full of computers, I can't easily discern whether the systems that run inside it are alive and beautiful. The relationships between patterns in the software that make it this way are not always obvious. Hence, our pictures must be more abstract and based on logical elements that are intrinsic to the system.
Iteration from most abstract to most concrete. When programmers want to solve a problem with a system, they start with a more abstract representation and get more and more intimate with the solution until they've got an abstraction that's concrete enough to generate the machine codes necessary to build the system. In the process, they break things, fix them, fix bugs, adapt to changing requirements, perfect the system, etc. and can keep re-generating the system from a code base that represents its most concrete abstraction.
Rapid change in abstraction. In software, the level of abstraction that programmers arrive at before generating the system gets raised over time based on the availability of smaller machines, reduction of cost, and increased performance. It doesn't happen as rapidly in architecture. The way they built a pyramid thousands of years ago and the way they're building a high-rise apartment building across Park Ave from VeryCoolBuilding aren't too different...I didn't see a guy wearing a hardhat with the label "Guido's Mob-Run Construction Co." punch a button and watch as machinery built the entire building and deployed it to its tenants.

Therefore, in software we need more hand-holding. Elements like pictures, source code, class diagrams, interaction diagrams, and stories are all very good ways to help the reader of a software pattern get its essence. However I also think that we can get a lot from the form that Alexander uses for delivery in his own work. In ComponentDesignPatternsFormat I recently asked readers what they thought of having all CDP patterns presented in AlexandrianForm.

-- PhilipEskelin