The Paradox of Learning Objects

This post originally appeared on the Software Carpentry website.

Warren Code recently forwarded this post by David Wiley, a serial innovator in open education and educational reform. In it, he recapitulates the history of "learning objects" and the paradox at the core of the idea of remixing and reusing teaching material. Since Software Carpentry is (sort of) trying to do exactly that, I think everyone who's currently teaching for us or helping us meet our first publication deadline should look it over.

In a nutshell, Wiley's Reusability Paradox is that "the amount of internal context of any learning object is directly correlated with its educational efficacy, while that same amount of internal context is inversely correlated with the number of aggregations the learning object fits into." More simply, teaching materials are most reusable when they are as generic as possible, but most effective when they are customized for a particular audience in a particular context, so, "the pedagogical effectiveness of a learning object and its potential for reuse are completely at odds with one another." As Wiley says:

The Reusability Paradox typically leads designers of learning objects to attempt to "strike a balance" between effectiveness and reusability. This generally results in materials that are neither particularly effective NOR particularly reusable across contexts. No one wants to trade efficacy for reusability (or for lower cost, or for anything else — as the recent Babson survey showed, faculty want proven efficacy more than anything else). And yet we do this all the time without really realizing it. Instead of targeting a specific audience and a specific context, almost all teaching materials adopt their own version of Wikipedia's Neutral Point of View. Educational materials — and learning objects specifically — try to be just generic enough so as to not be offensive to anyone. They lack what Giant Robot Dinosaur calls a Minimum Viable Personality.

For example, take teaching materials about the Ruby programming language. Here are the first three results that come up for me after searching for Ruby tutorials — Ruby in 20 Minutes, My First Ruby Program, and Ruby Quick Reference Guide. They're each so bland and generic as to be almost indistinguishable from each other. Contrast these resources with Why's Poignant Guide to Ruby. You can actually distinguish this resource from the others. It was obviously written with a specific audience in mind — and they love it. But the internal context created in Why's Poignant Guide — the cartoon foxes, Blix the cat, etc. — are SIMULTANEOUSLY what makes it awesome for a specific audience and what prevents it from being reused more broadly.

Wiley's solution is open licensing:

The way to escape from the Reusability Paradox is simply by using an open license. If I publish my educational materials using an open license, I can produce something deeply contextualized and highly effective for my local context AND give you permission to revise and remix it until it is equally effective to reuse in your own local context. Poof! The paradox disappears. I've produced something with a strong internal context which you have permission to make fit into other external contexts.

Respectfully, I think this is simplistic. Learning someone else's material well enough to revise and remix it takes time—so much time, in many cases, that it's more efficient for any particular teacher to create their own lesson.

But the same is true of software, and the similarity between the two is what led us to the model that Software Carpentry uses. The first is that formative review works better than summative review. Giving people feedback on their code when they're "done" doesn't work as well as reviewing small changes incrementally as they're written. Equally, picking up someone else's learning object when it's "done" isn't going to work as well as helping to shape it while it's being written.

That leads to the second realization: the tool shapes the hand. We shouldn't go off into our own separate corners to decide what to teach, then cobble together bits and pieces of lessons to teach it. Instead, we should talk to each other and learn from each other in order to figure out what's worth teaching, as well as how best to teach it. One of the key benefits of code review is that it spreads understanding around; the discussions going on in our lesson repositories are (I hope) helping instructors understand each other's thinking and the reasons why our lessons cover what they do in the order they do.

Another insight from Wiley's article is that small is easier to remix than large. Programmers have known this for decades: small single-purpose functions that can be combined in lots of ways are much more reusable than monolithic blocks of code that do a thousand things, most of which you don't actually want. Software Carpentry is now moving this way, e.g., by breaking our lessons into many smaller pieces. (I now say that if you want to put an exercise in the middle of a topic, you should break the topic in half. I think this is analogous to the programming heuristic that says, "If you want to return values from the middle of a function, what you really have is two functions," but on the other hand, maybe I'm just looking for analogies...)

Overall, I think that Wiley nails the shortcomings of naive learning objects, but his discussion of reusability misses the mark when it comes to the practice that has made open source software possible: merging. Taking what you've done and incorporating it into my lesson is useful, but offering you my changes to improve the original is more useful still. Open source software wouldn't exist without that, and as I've argued before, I don't think truly open educational resources will take off until pull requests on lessons become the new normal. I hope Software Carpentry's experiments with that will help make it a reality a little bit sooner.