Xp Writing Patterns

What about the happenin' notion of doing ExtremeWriting? to create patterns, pattern languages, or pattern catalogs? Rather than get cerebral and overly analytical about your efforts, why not just jot down some scrappy forces or a deficient motivation ASAP, then work it from there? Some pattern-based projects on wiki seem to be using an approach like this.

--PhilipEskelin

Consider the idea from the perspective of ExtremeValues.

Aggresiveness is central to your idea.

Communication is quite evident in the ComponentDesignPatterns project. It must surely be critical to any such undertaking by more than one individual.

Simplicity seems to me to be a worthy goal in any pattern or pattern language. Personally, the patterns that really "resonate" tend to be quite simple. I've read others, however, that were not at all simple. In such a case, it feels like something is wrong. Is that just the feeling of not yet "having" the pattern? Or is the pattern not as simple as it shouild be? Are there multiple (proto-)patterns luring in there waiting to be factored out? Or are some patterns just inherently more complex?

Perhaps this is just a naive perspective rooted in my inexperience with patterns. I would like to here from some of the "gurus" on the issue of Simplicity.

I'm not sure how Testing fits in. Testing in the sense of the XP practice seems to be inapplicable. A pattern isn't a machine with a hand-crank that can be turned to produce a result. It's not a machine at all. Instead, it serves as input to the wetware machines we all carry around.

Perhaps Testing as an XP value still applies. A pattern isn't an end in itself, it's a means. A pattern must be useful. But how does one confirm that a pattern is useful? Is the RuleOfThree enough?

--KielHodges (looking forward to an educational experience ;-)

I guess testing of a pattern is other people reading the pattern. However, compared to software where you can tell if a piece of code passes or fails its unit test, you can only know that a pattern has something wrong with it or is better than it used to be. There is no black-and-white sense of correct/incorrect.

If a reader "has the pattern" then that can be considered a point in favour of the pattern. If they feel that the QWAN is missing, then that shows something needs to be done. From a pattern writer's perspective, this is what is fantastic about using the WikiWikiWeb to document patterns -- you get this kind of feedback very quickly and this helps you improve your understanding of the problem domain.

This quick refactoring of patterns and hyperlinking of patterns allows a set of interrelated patterns to organically grow and evolve, perhaps to one day become a PatternLanguage. As an example, see the discussion of at the bottom of TreeStructure, one of the WebsitePatterns, that led to the identification of a new pattern, MultipleCrossSections, that was obviously related to VisibleContext and led to an understanding (on my part) and refactoring of SelfSortingAudience, which was a form of EasyOrientation.

--NatPryce.

Story: In my own experience workshopping a pattern at PLoP, I had mined the pattern I submitted out of a prior experience. It seemed to have the rule of three. First I documented the existing implementation in pattern-like form. Then I started not only iterating the idea, but the model and sample itself. As it evolved, I struggled with the PLoP submission deadline and too much over-analysis of what I should be doing.

Then I just (a few days late -- SteveBerczuk was nice enough to give me a few day's leway) formatted to the best of my ability and submitted it right before getting a few hours until I had to go to work the next day. Finally, amazingly, it got accepted. To me, the most rewarding experience was the shepherding experience, and the workshop experience. Both of those were what you could consider testing.

And I wholeheartedly agree with Nat -- WikiWikiWeb is a great place to throw something incomplete up into a wiki page, then see others fill in the blanks. Recently I had this ProtoPattern idea called SplitDesignTimeFromRunTime?. Before getting a chance to add anything, BradAppleton commented that we seemed to be absent of forces. This is testing and listening. After throwing up a few forces to start off SplitDesignTimeAndRunTime, Nat and Stuart added some comments, then Kyle added a great Intent and Motivation. Boom, within about six hours we had a full page of what suddenly looked like a promising pattern.

To me, six months from now, SplitDesignTimeAndRunTime could be totally different -- re-named, dropped, changed, whatever -- but the whole idea is to start with something wrong and then iterative fix it as a group. It's also a great learning experience. On top of that, for me, it has been a fun and rewarding one too.

--PhilipEskelin

CategoryPattern