This is a message originally sent by WardCunningham to the PatternsList in January 1994. I can't find it archived online anywhere. SteveBerczuk sent me an OCR'ed version he had, which I just cut and pasted in. -- DougLea
Friends - I'd like to encourage all of you to get your pattern pencils out and get to work on your submissions to the PLoP'94 conference. To that end, let me suggest a few steps that have helped me get something down on paper. Also, I've included the introduction and section headings from what I expect to be my own submission: a pattern language I call CHECKS. But first the steps...
1) Pick a whole area, not just one idea. I like subject matter that is practical but seldom explored in a text book. You know, the kind of stuff you have to learn from your colleagues on the job. The discussion on the "patterns" list got me thinking about checking data.
2) Make a list of all the little things you have learned through the years about the area. Imagine that your kid brother has just taken responsibility for this area on his first big job. You're getting together this weekend. What are you going to tell him. Make a list.
3) Cast each item on your list as a solution. I like to write a sentence with "therefore" in the middle. You will have to think a little deeper here to figure out the forces that bear on your solutions. It's ok to speculate. I find this to be a rewarding activity since I often find new reason for what I do.
4a) Now write each item as a Pattern. I've come to favor a four paragraph form where the second paragraph ends with the pivotal "therefore:". This is a good time to flip through Alexander's Pattern Language. I feel my work has always improved when I more closely mimic his style. I'm just now learning to make the first and last paragraphs carry weight. These are the ones that link a pattern with others in the language.
4b) Organize your patterns into sections. Write a little introduction to each section that lists each pattern by name. You may find you need to adjust your linking paragraphs as you study the higher level structure of your patterns. Try to keep 4a and 4b fluid as you write. As you become more familiar with your patterns you may find that they organize themselves.
5) Now write an introduction to your pattern language that hints at the forces you will be addressing. Pick a good name too. And send a summary to the "patterns" mail list.
So, that's my formula. I think you'll find that even a sketchy pattern will stand better with other patterns around it. Now here is the promised summary of my CHECKS pattern language. This is offered for the immediate use of members of this list and should not be considered publication. Good luck with your writing. -- WardCunningham
Look for CHECKS at http://c2.com/ppr/checks.html.
See a recent companion piece, http://c2.com/doc/TipsForEditors.html.
Pattern languages describe an architectural school or style; have that school or style firmly in mind when working on each pattern and on the overall structure of the language.
Pattern languages are a DirectedAcyclicGraph (DAG) of patterns. There are many meaningful paths through the DAG. Don't focus on the paths through the DAG, but on the relationships between adjacent patterns - that leaves the designer free to choose a suitable path.
What are adjacent patterns? Each pattern's Context section should mention the patterns it presumes have been applied already as preconditions. Each pattern's ResultingContext? section should suggest patterns that may follow to balance unbalanced forces.
Individual patterns in a pattern language should encapsulate their own forces. That makes each pattern independent, so it can be applied independently of other patterns (without too much concern for the big picture at any given point). Good patterns should always be like this, but it's particularly important when the pattern is in a pattern language.
Try to make the patterns fit together in a way that no backtracking is necessary.
Use and reference existing patterns where possible, instead of writing your own.
Provide a good index; a graphical map of some kind is also very useful.
Not every collection of related patterns is a PatternLanguage; some are just a PatternSystem; some are just a PatternCatalog. Too often, things that are called patterns and pattern languages are just steps (rather than structure-preserving transformations) and recipes. Don't try to make it a pattern language unless it is one.
You won't get the patterns right, or the structure right, the first time, or the second time, and probably not the tenth time. Writing good pattern languages is hard - have patience, iterate, and seek input and feedback.
A pattern language is literature. Write it to entice someone to read it.
-- JimCoplien