Powered by Elgg

Pat Parslow :: Blog :: Patterns, training, learning, finding solutions

April 23, 2008

First of all, a couple of disclaimers.  I suspect I am a cynic, and I am going to speak in generalities based on my experience rather than the results of studies on the subject.

 

I would like to thank everyone involved in the Pattern Language Network discussion today - it made me think.  Whilst the nature of this post is probably fairly anti-pattern (as in, being against patterns) hopefully it will come across as intended, more as a discussion topic than a hard and fast point of view.   At the very worst, it is just my point of view Smile

 I am from a software engineering background (and a civil engineering background), but, to my mind, have managed to stay blissfully away from design patterns.  Generally, I have found, the programmers who talk of patterns are the ones who seldom solve problems themselves (and even I have to admit that I know exceptions to this generalisation).

To approach patterns from a different point of view, initially, I see the way I taught basic computing skills to adult learners a few years back as being in terms of patterns.  I would explain how to achieve a goal given a certain context.  My learners became proficient up to a point - if things went wrong, they had no immediate way of solving the problem, and something about the training they had had meant that they did not feel confident exploring ways to put things right.  When I switched to a new way of working - showing them how to learn how to use the packages, and then demonstrating some things that can go wrong (so that they could recognise typical symptoms), they became much more proficient both at disaster recovery and at  general operation.  This could still be described in terms of being a pattern, but might more commonly be thought of as an anti-pattern.  Not in a proscriptive sense, in that I didn't suggest they shouldn't do X, but in a permissive sense, where they learned that you can find your way back out of a hole in the ground.

I think that I see patterns as being very much linked to training, as opposed to education.  What is more, I think that the existence of a set of recipes which can be used to find solutions to problems will always have a tendency to reduce creative, imaginative solutions.  that is not to say that they are not useful.  If you need to get something up and running quickly, following a pattern is probably your best way forward - in the short term.  But if you need to be able to remain on top of your game, I think you are going to be better off exploring possibilities yourself, generally from scratch (in the context of whatever communities you are part of) and using a list of anti-patterns to give guidance about things to avoid.

The other general problem I have with patterns is that they tend to be misused (in my view).  They tend to become a prescriptive, static, set of guidelines which people venerate and won't modify.   In an engineering office I used to work in, the design patterns were used to such an extent that engineers seldom did more than follow the recipe.  In one case, I was lefttrying to find out why some reinforced concrete had failed under loading - because the design pattern had been followed without consideration for the fact the context was not 'complete'.  Fortunately the error was merely highly expensive rather than costing any lives.

 As I believe George Siemens might point out, with the shortening half life of knowledge in todays information economy, it is surely important to emphasise the meta-patterns more than the patterns.  We need to look at how to successfully determine how to achieve the results we desire, more than at how to just achieve the goals?


Overview for Keywords: jiscemerge0408, learning, Patterns, story, training

Blogs with Keywords: jiscemerge0408, learning, Patterns, story, training

Posted by Pat Parslow


Comments

  1. Interesting post and glad the session was thought provoking. First to the points where we can agree. Patterns have undoubtedly been misused - both in the way you describe and in the way they are developed. I would go further actually and say that IMHO patterns have been more abused than not - and that has not done them any good at all. A lot of so called patterns out there are no more than someone's good ideas, put out in a particular form, and often tied inextricably to a particular technological solution. An example that springs to mind is the wizard in interaction design. Now there may well be a pattern that covers step by step task completion or something similar but a wizard is an application - one particular instantiation of such a pattern - and not the pattern itself. For me a critical factor of a pattern is that it is observable in practice - and repeatably so.

    I disagree that patterns necessarily lead to derivative design. If they are poor patterns that are heavily rooted in a particular application then that might be the case. But architectural patterns certainly don't and good design patterns don't need to. My experience with using patterns with students has been the opposite of yours - my students found them thought provoking, used them to assist them in evaluation, and ultimately all produced very different and competent designs. But this was in interaction desgn rather than software development - and I do think patterns in these disciplines are quite different.  A key to usefulness for design is the pattern language - and the Gang of Four never even claimed to produce a pattern language - whereas attempts have been made to do so in web design etc.

    All that said I think the key to what we are trying to do is find ways to effectively share and make use of successful practice - patterns are a useful starting point for us because this was their original aim - but we are not precious about it. We want the community to engage in the debate on how we can effectively represent practice - and what are appropriate representations for this. It may end up being a pattern, or a variation on the form, or indeed something completely different. The process of determining this will be as informative as the end result I suspect!

    Thanks for your thoughts on this. 

    Janet FinlayJanet Finlay on Wednesday, 23 April 2008, 21:05 BST # |

You must be logged in to post a comment.