« RE assertions in JUnit | Main | Review: JUnit In Action »
March 15, 2004
A Pattern By Any Other Name Would Still Sell As Well
My current bedside table book is entitled "The Manager Pool: Patterns for Radical Leadership" and I started reading it principally because of the "patterns" reference. The book is basically a large collection of software development team management tips, each one considered a pattern and grouped into general categories: Psychological and Retentive, Behavioral and Explusive, Strategic, Tactical, Environmental. Each pattern is described simply in about 2-3 pages and is linked to other patterns where appropriate.
However, I don't intend this to become a book review - I have another point to make:
Upon reading the first couple of pages of this book I was horrified at the fast and loose interpretation of the word "pattern" used by the author. There was none of the usual decomposition of the so-called patterns into standard sections, as I was so used to from GoF, PoEAA and the like. Instead, each pattern simply had an opening statement, followed by a lengthy narrative, a short conclusion and then cross references to other patterns.
And then it dawned on me (or so I thought) - the author was appropriating the term pattern to attract a larger readership lulled by the siren call of one of the most popular memes in software development at the moment. How cunning!
However, my occupation of the high ground of moral outrage was short lived. Soon came the dawning of the second age...
It took me a while to realize that I'd been acting under the misapprehension that something wasn't a true "pattern" unless it fitted the GoF stylesheet and could be documented in respect to its background, implementation, where to use it, etc. I'd forgotten that a pattern is nothing more than a "thing" that is commonly encountered or used in a particular field.
Furthermore, patterns are (obviously) not unique to software development. They may/may not be considered best practice in a particular domain, but are usually of sufficient quality (AntiPatterns notwithstanding) that their documentation can greatly assist people in identifying common situations amenable to the patterns and applying them appropriately.
Hence, the topics covered in this book are truly patterns - irrespective of the format of their documentation. I was thusly humbled.
"And the book itself?", I hear you ask: As with most pattern type publications, everything is very much common sense (well, duh!). I usually find these books better used as reference items than texts read cover-to-cover.
Posted by Andy Marks at March 15, 2004 07:17 AM
Comments
It's worth pointing out that the pure Alexandrian form of pattern isn't what the GoF used either... look at the PatternForm discussion on Ward's Wiki; there's a good half-dozen or so main forms. I'm personally fond of Beck's format.
(And yes, I'll probably comment on at least half your posts here... ;)
Posted by: Robert Watkins at March 31, 2004 09:03 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)