Why is a Pattern different from other forms of guidance?

The Microsoft Solution Engineering Team in which I work has just started its own blog - so I wrote my first post on the subject of reintroducing patterns and the qualities associated with a good pattern. Here is an abstract from the blog post...

Why is a pattern different from other forms of guidance?

For this first weeks post I am going to focus on the topic of why a pattern is different from other guidance. This seems extremely timely because there are a large number of books / white papers / guidance hitting the press most of which will confuse the concepts listed below - and leave you no better off when the next major paradigm shift occurs - and leave you feeling like you have to relearn everything you thought you already knew.

When asked what a pattern is the standard answer you will get from a pattern geek is something along these lines:

     "A pattern is a proven solution to a problem, described in context"

As a one liner this is reasonable - but it doesn't really help you understand what the qualities of a pattern are that separate them from other forms of guidance - nor does it help you discern a good pattern from a bad pattern.

Considerations when Writing and Reviewing Patterns

Here are a couple of considerations that I look for when writing or reviewing patterns.

• Actual Solution. A pattern describes an actual solution to a problem - it isn't just an abstract principle
• Based on Proven experience. The solution is based on proven experience - ie it is something that has been tried, tested and refined over a number of solutions at a number of different organizations
• Platform Independent. The solution is described in a platform independent manner - ie independent of implementation - hence it is durable. This would allow the same logical solution to be considered regardless of what version of a platform you are running on, or potentially even what platform you are running on.
  • Note that the pattern on its own may not be useful to many folks - which is why many pattern guides will have a separate piece of guidance demonstrating how to implement that pattern on a specific platform - thus increasing the relevance and applicability for that pattern.
  • patterns & practices used to call these implementation patterns - I personally think a "How To" style of document is sufficient.
• Include Tradeoffs. Patterns should include architectural tradeoffs that you must consider when selecting the pattern
  • The forces that steer you towards using the pattern or away from using the pattern
  • Benefits and considerations that you must consider if you do apply the pattern
  • Relationships to other patterns that might be good substitutes or might well be used in addition to this pattern
• Atomic. Patterns are also typically atomic - following the Single Responsibility principle. If you see a pattern solving a number of problems it is usually a sign that the pattern should have been split into multiple patterns.
• Named. And of course the pattern has a name, that if well thought out will establish a vocabulary for our industry.