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.
Looking forward to more posts...
I grew up in both Australia and New Zealand - a long way from the US and the UK where home computing