I have become comfortable with formally labeled sections of a pattern such as name, context, problem, solution, rational, etc. as long as the solution section immediately follows the problem section. The reason the problem and solution sections should be adjacent is that I have tried to follow the advice that the problem section builds up a tension for which the solution section provides a catharsis. This has not been intuitive. More than once I have had to move verbage from the solution section to the problem section. But in each case, the pattern was improved. Another aspect of formally labeled sections is that narrow columns of text are needed to tame the amount of white space introduced by the section headers.
The ``forces'' section is currently rather weak because the many missing patterns of this ``distributed computing'' pattern language need to be identified before one can properly begin to identify and sort out the forces.
Working with patterns has given me additonal insight as to why I have such a difficult time with the waterfall ``mythodology.'' I generate programs by tackling different levels of abstraction in parallel. For example, at the beginning of a development I'll discuss both high level structural issues such as the boundary between the application and the platform, low level issues such as what kind of protocol we should use over a fiber link, and a myrid of miscellaneous issues such as source code control strategy and tools. However, there are other topics, such as measurement collection, that I don't even want to start designing until after The Waterfall says the design phase is done. I can envision a methodology based on generative pattern languages that allows the architecture and design of some aspects of the system to proceed by a considerable interval the architecture and design of other parts of the system. For several years I have thought of the software development cycle as a pail of water freezing into ice. It doesn't freeze top-down or bottom-up, it starts crystalizing throughout the pail around loci of impurities. In the case of software design, I prefer to think of loci of understanding or insight rather than loci of impurities.
One lesson learned at the writers workshop is the conflict between using the patterns initially as expository material and using them latter as a reference work. In the expository mode, many examples should be included. However, in the reference mode, the many examples make it more difficult to find the nuggets of information. Ultimately, we may be able to use hypertext to resolve this conflict. While we are constrained to the printed page, I'm experimenting with using a smaller font for the examples so that they may be easily skipped during subsequent references to the pattern.
My experience with these patterns runs the gamut of having used a pattern systematically since the early 70's to having just learned about it. Like Alexander, eventually each pattern's ``utility'' will have to be graded. However, I have yet to do a project in which all of these patterns were systematically utilized. One reason is that until this documentation effort, many of these patterns were intuition instead of knowledge. Another reason is that some of my colleagues think object-based programming means coding in C++ rather than my meaning of ``understand your data.'' Culture clash is a force I haven't even begun to consider how to resolve. Another reason I haven't systematically practiced this pattern language is that there are many patterns still missing.
My understanding of patterns is still in that initial stage where, by the time I write ten pages, I have gained an insight that makes the ten pages wrong. The insight that invalidates the next section is that time threads should have not followed data structure diagramming. Instead, the phases of each technique should be interleaved with each other so that they complement each other. Just as educators have learned that some students are visual oriented while others are aural or hands-on oriented, I'm concluding that some designers are noun oriented while others are verb oriented. I think one of the potentials of pattern languages is that they will allow multiple paradigms to coexist and complement each other and allow us to quit discussing which approach is ``correct.''