Learning Objects Aren't Legos, Part I

I’ve been looking forward to having the time and energy to respond to Stephen’s most recent response to the whole pattern language of educational experiences conversation.

Stephen writes:

Even so, [Michael] effectively finds the source of the tension: “I believe that the rules for re-using experience patterns and the rules for re-using content are respectively analogous to the rules of syntax and semantics.” I would say they are analagous in use, but they are not isomorphic – there is nothing, say, in the placement of an image on a web page, or the playing of an audio clip with some video, that corresponds to the rules outlines in Chomsky.

My initial reaction was that Stephen’s point is so obviously true that it’s almost not worth saying. But that initial reaction was wrong. Because the mistake that Stephen is warning about with respect to the language analogy is exactly the mistake that the majority of accounts of learning objects (especially the earlier accounts) have made with respect to the analogy with object-oriented software.We want to think that learning objects are legos, i.e., that they can be snapped together in an infinite variety of ways without concern about how one fits with the others. However, anyone who has substantial experience trying to re-use learning objects knows that this is false. It’s often hard to even re-use learning objects (without modification) in a new course about the same topic if the objects you want to re-use were written for a different audience. How did we get it so wrong?

The answer is, the same way we usually get it so wrong, i.e., by becoming so infatuated with the certainty of and, frankly, the respect garnered by the sexy science or engineering subdiscipline du jour that we forget that analogousness is not the same as functional equivalence. In the case of learning objects, the discipline that inspired our collective infatuation was object-oriented programming.

The notion of “object-oriented instructional design” first surfaced around 1997 and was explicitly inspired by object-oriented programming. (I distinctly remember an article on this topic appearing in Performance Improvement Quarterly in either 1996 or 1997; unfortunately, I don’t have access to archives at the moment to find the citation.) OO programming was especially sexy and buzzy at that moment. And hey, if it worked for software in general, why shouldn’t it work for educational software? Why can’t we just specify some programming interfaces to string content objects together (e.g., SCORM) and achieve the same kind of sexy re-usability as those newly popular computer geeks who made that crazy Java thing?

Two reasons. First, we romanticized OO programming. If you talk to anybody who has actually done a significant amount of it, they will tell you that they have some of the same problems re-using software objects that we do with learning objects; namely

1. Figuring out how to abstract code into an isolated, re-usable chunk is far more labor-intensive and requires much more skill than a more traditional approach.
2. Even when the objects are properly abstracted, they can’t necessarily be dropped into any old program and expected to work. A certain amount of rewriting is still often required.

Beyond this, software obects can have one critical property that learning objects cannot have: encapsulation. To the degree that a software object is re-usable, it’s because it is possible to write down a simple list of all the various ways that other software objects might need to communicate with it and specify explicit protocols for that communication. In other words, we can compactly and effectively describe how the top of our lego needs to fit into the bottom of other legos.

But meaning in human-to-human communication doesn’t work that way. The ways in which the tops and bottoms of content “legos” fit together is highly dependent on rich context. For example, take the sentence, “People are dying to get in there.” If it is my father saying that sentence as we gaze upon a cemetery, I know that it is his poor attempt at humor, and that attached to it is all the interpersonal history that we have regarding his notoriously bad and oft-repeated jokes. In other words, the top of the “people are dying to get in there” lego changed based on the other legos that were near it. Because of this shift (and the generative nature of it), it is impossible even in principle to comprehensively specify all the bumps and grooves on the top of our learning object legos because those bumps and grooves are not static and independent. (For a thorough and delightful exposition on this problem, read Stanley Fish’s book Is There a Text In This Class?.) For this reason, analogy of learning objects as software objects strains to the breaking point when we take it too literally.

Stephen is right; we must be very careful not to mistake an analogy for an isomorphism.

But does this mean that we have to give up on learning objects? Or that we can’t have some sort of building-block-like structure for them? I don’t think so. I’ll outline an alternative in part II of this thought.