rElearn

The growth of the Virtual Learning Environment (VLE) is a classic example of Institutional Learning. The size of the the feature set of VLEs, taking Moodle as an example, is explosive. The complexity and growth of Moodle occurs at many levels. From hardware right up to software through an application stack. Consider just the core Moodle code base itself: Between August 20th 2002 and October 15th 2008 there were  62 new releases (versions). Of these nine were major version releases and many minor release versions contained significant new or amended features (i.e not just bug fixes). Are teachers aware of the full feature set of Moodle, of what it can do? Could they keep up with its growth? Are teachers aware that important pedagogical decisions are being made by software developers  in Australia that will shape the online classroom for years to come?

Even the coders of Moodle are not the sole “designers”  of an Institutional Environment for online learning. At least not as much as you (or even they) might suppose.  There are currently 17,767 bugs recorded in Moodle’s bug tracker. An increasing amount of Moodle’s development is dedicated to finding and then tracking the fixing of bugs. What are bugs? Can we consider them in any way analogous to the mutations in genes that drive biological evolution? We can certainly say that bugs are unexpected and unintended. They were not designed and are generally considered harmful. Bugs show that software, once it becomes sufficiently complex, cannot be easily designed and planned in a predicable fashion. Development becomes more akin to trial and error as developers can never be sure exactly what effects a given change will have. Software is evolved.

What if bugs could be avoided? What if software developers could completely and successfully implement a designed feature? Even in this case there is would be no certainty that students and teachers would use a given feature as it was intended to be used. We are creative tool-users and like to adapt things to our needs in ways for which those thing were never designed. For instance Google was always intended to be a search tool. However many people now use it as a navigational device, ignoring the browser address bar which is the “proper” way to go somewhere.

So we have a process as follows:

• • Moodle’s developers try to build features into the system
  • These features will not be realised exactly as they were conceived
  • Teachers and students (via teachers) will not use many of these features
  • The small subset of Moodle features that are actually used will be used in unpredictable ways

The chain that leads from design to student use is a long one. Hence we need to be wary when we use the term “design”. Institutional Learning is complex and not predictable. Learning is not designed.

Bugs tell us something else. As systems become more complex and more embedded within our lives their stability becomes more important to us. Up-time and stability become more important than some new innovative pedagogical feature. There is more to risk. Systems become more conservative, more concerned with preserving themselves. It is natural to be  experimental when there is little as stake. Then, as an organisation becomes reliant on a system, change is considered more costly. In computing this phenomenon is well illustrated in the concept of “backward-compatibility” where progress and growth must be balanced with existing standards or metaphors that people are already productively using.

Bugs may seem wholly negative and unintended, but they aren’t. How many bugs are we willing to gamble to gain something new? When do we cross the threshold between trying to gain something new and trying to protect what we have? Bugs are the currency of order.