structure and process in patterns
One of the simple heuristics I use when I am helping someone improve patterns is to make pattern names be noun phrases. But this is more than a heuristic. Patterns should describe structures. When you are "using a pattern", you are building something. This is easy to see for OO design patterns, which is why all the patterns in "Design Patterns" have a structure diagram. However, it is just as important for process patterns like "Pair Programming".
"Pair Programming" is a clever phrase because it is both a noun phrase and a verb. . The fact that it is a noun phrase lets us say "Pair programming leads to better communication" Nevertheless, it is a practice, something people do, so we can say "We are pair programming". It is easy to think that there is no structure involved in it, but that would be wrong. Walk into a room where people are pair programming and you can see two people per machine. They aren't just sitting there, they are talking to each other. If you watch long enough, you'll see control pass back and forth. There is a structure to the relationships between people, and learning pair programming means learning these relationships and how to make them work.
Although we call patterns about how people work together to develop software "process patterns", in fact all patterns involve both structure and process. Sometimes it is easier to see the structure, and other times it is easier to see the process, but both are important. "Design Patterns" tends to be strong on structure and weak on process. Joshua Kerievsky's book "Refactoring To Patterns" shows that there is just as much process in these patterns as in other patterns. A lot of people seem to follow the errors of Design Patterns and focus on structure to the exclusion of process. A pattern description should tell the reader how to create the pattern in a system where it doesn't exist, and many pattern descriptions do not.
One of the things that helps me think about process is to imagine a system without the pattern. What would I do to use the pattern in the system? What alternatives are there to the pattern? When I can see "before" the patterns, as well as "after" it, I can see the pattern as a transformation of the old, pre-pattern, system into a new system. That is when I understand the process that makes the pattern.
Structure and process are both important in patterns. A pattern should describe what you are building, and it should tell you how to build it.
