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