Software Patterns, the Old and the New

One of the reasons I started thinking about blog use cases yesterday was an indirect link between a piece by Michael Sampson and the Wikipatterns site that I noticed has got a few people excited.

Michael Sampson's point is to explain that outcome is more important than the tool, but that it can be affected not only by software functionality but also personal preferences towards a particular software tool:

"although the outcome quality of the coordinated effort may be similar for one technology vs. another, if you face the choice of turning the majority of people off by your choice of tooling .. that is, if there's a substantial difference between people's satisfaction with the process as influenced by tooling choices ... investigate different tools."  

In other words, if people hate product X, no matter how good it might be, then go with product Y or even Z because solution "elegance" isn't the same a business outcome. That's a good point.

Now this brings me to Wikipatterns:  There is nothing significantly new in the advice contained in Wikipatterns that we haven't already seen with issues around adopting earlier forms of collaborative software. But in the context of Michael Sampson's post, this doesn't change the value of Wikipatterns - its a very well executed site with clear explanations and guidance, all using the right jargon and addressing specific points of functionality in Wiki software.

So what's my point?

I want to reiterate that there is no wrong way of using collaborative and social media software tools, only a best fit with your objectives. And I don't care what you call it either. However it is a mistake to dismiss the experiences of the past because the language is different or the tools aren't as slick. For example, one of my favorite "pattern" resources has always been The who, what and why of knowledge mapping, which provides the following roles in making and using knowledge maps:

• Map maker - creates the details and sets the usage pattern of the knowledge map
• Map users - use maps in order to accomplish their tasks and to develop learning potential
• Map innovators - alter existing maps through use, reuse and diffusion of innovation
• Map champions - uphold the need for knowledge maps as providing a competitive advantage for the organisation

They sound like they could be very applicable to a Wiki, don't you think?

Similarly, we should not be afraid to draw on resources like Wikipatterns even if we don't think we are using a "Wiki" in the purest sense. These patterns are applicable in many other collaborative contexts.

But what I think is missing is that we do need to be clear about exactly what the new patterns really are, else the outcomes will be the same and it will leave some people wondering what the hype was all about.

Technorati tags: Michael Sampson, Wikipatterns, Wikis, Social Software, Knowledge Management, Groupware, Collaboration, Knowledge Maps, Software Patterns, Enterprise 2.0