Reuse, Standardisation and Calcification

As we embark on the development of something, anything in fact, we no doubt will find ourselves in situations where we are reusing part of previous work we have done. Programmer uses the technical term "function" to encapsulate a block of code which is used in several occasions (reuse). Later, of course, we have methodologies such as object-oriented development etc. This post is not about such technical details.

When we write our lesson plans (is there anyone still doing this?, ok, assume we do), we found ourselves repeating several patterns which we are comfortable with. May be it looks like "revision of previous lesson, introduction of new idea, details, examples, more details, more examples....". Again this is a re-use, a reuse of the pattern.

The conversation style I am using in Conversation With My Evil Twin has a template behind it. I always have a "background" section and a boilerplate passage "Once upon a time, on a sunny evening ...."

When a team starts to work collaboratively on a project, we begin to introduce guidelines, rules etc in order to make the reuse more efficient, ie minimise the re-invention of wheels. (Ok, the guidelines and rules are also introduced for other reasons too, but here we focus on those guidelines and rules which are related to re-use). When the team is small and close, these guidelines and rules are negotiated and formed informally. As the collaboration team grows, with more members from more diverse background joining the team, this process of articulating the guidelines and rules starts to have a life of its own. This is called the standardisation process. As long as this process is driven by the active users (members of the collaboration teams who actually use the guidelines and rules in their daily work), these guidelines and rules are fluid, changing as needs arise and continuously re-negotiated. However, when the process is taken over by "managers", this is then driven by a completely different set of motives and agenda. "Political" considerations become more and more important. These start to surface and enforced: "stability of standards", conformance and examples where organizations attempt to 'refocus' anyone who is perceived as doing any innovative work 'out of the box' because this is perceived as either 'non corporate', 'off message' or just plain inefficient (Derek Morrison, World's largest deployment of Moodle? (part 2)) James Gosling call this calcification in an 1990 online article (http://www.java.sun.com/people/jag/StandardsPhases/index.html) which is no longer available online.

Once certain "standards" are recognised as important and strategic by the upper management, the power of negotiating, modifying, extending etc of these standards are taken away from the actual users. Actual users are typically disconnected from the standard process (may be the users of standards are not interested in the political battles of setting standards, or they are deem as not representative enough from the organisation's point of view that their representation are replaced by more "senior" members who have no hand-on experience of the "product" they are trying to standardise.)

I will stop here and let you imagine what will happen next ...

Does this sound familiar to you? I hope not.