I’ve been chatting with Christian Kohls of Knowledge Media Research Center about pattern languages, workshops, community engagement, and the big picture. The discussion brought up some issues which where floating around EuroPLoP, and resonated with recent discussions on the Liberating Voices mailing list (pss – the book is out).
I see three major challenges pattern language communities to address:
Validity
What’s the scientific process of showing that a pattern does what it claims? Is it science, or is it art? What kind of evidence does a pattern need? How can we get the scientific community to accept patterns as a valid tool of knowledge production?
Even looking at Christopher Alexander’s patterns, the question arises. Alexander has a “confidence” measure, but what is it based on?
Resonance
In the Learning Patterns project, we noted:
Paradoxically, often as more expert knowledge is embedded in a pattern language it becomes less accessible to novices. The Learning Patterns project has tried to address this issue by a small set of Trails which accompany our pattern language.
But perhaps the problem goes deeper. Again and again, at every workshop we run, we see how hard it is for people to “get into the pattern groove”. Primarily, patterns are about abstraction without loosing context – and I think that is precisely what most people find hard. No wonder patterns have caught on so well in software engineering communities. After all, abstraction in context is what software engineers are trained to do.
So how do we break out of the cosy cult of patternisers, and make the knowledge we accumulated accessible to the wider public?
Aggregation
Once there was one pattern language for architecture (Alexander’s). Then there was one for software (GoF). Now there’s hundreds. Spread all over the place. Patterns are supposed to capture the essence of a recuring problem and its tried and tested method of solution. But they are supposed to capture it ONCE. In a way that can be referenced, linked, composed into larger structures or decomposed into sub-elements. What we’re seeing now is a fragmentation which defies the core purpose of the project.
How do we avoid reinventing wheels? How do we make sure that we build on each others’ work as much as possible, and aggregate design knowledge systematically?