, 3 min read
Death of Learning Objects
Millions were invested in Learning Object initiatives by most Western governments and nothing came out of it. David Wiley reflects on the failure of Learning Objects.
For a very long time now (in 1999, in 2000, and heck, NSF even gave me a CAREER award founded on this criticism in 2002) I’ve been saying that the idea of LEGO-like assembly of resources simply will not work from a learning perspective. The role of context is simply too great in learning, and the expectation that any educational resource could be reused without some contextual tweaking was either naive or stupid. I will here attribute learning objects’ inability to live up to the incredible hype and investment they received to the fact that the premise of the possibility of simple reuse was simply wrong.
The whole learning objects field of work turned into a giant software engineering exercise aimed at answering the question “can your content send scores for true / false items to my management system?†Because the term reuse (as used by many more people than just me, I’m certainly not trying to hoard all the blame here) was only partially understood, learning never really got into learning object systems. If anything, they were “technically interoperable content systems.â€
To me, what’s interesting is this is how quickly people and funding agencies fall pray to half digested ideas. Learning Objects were based on what some people perceived Object-Oriented Programming to be. While Object-Oriented Programming was not an all out failure, as an experienced programmer who built industrial strength code (and industry strength code!), I know that, while the concept of an object in programming is useful, conceptually, it doesn’t do much for reuse. It would be nice to think of building software as playing legos, but as with all analogies, it is overly simplistic. As David would say “The role of context is simply too great in programming.” I simply do not give away “objects”. What people give away are APIs or packaged code. But even well documented pieces of code, whether they are made of objects or not, are hard to reuse, in general. It may not look that way, but designing APIs, that is, reusable code, is not easy. It is done on purpose and by very good engineers who spend a great deal of time perfecting their work, and they rarely get it right. The Java API, while quite usable, often feels amateurish and it took a lot of time to become as good as it is now. People who create objects on the fly for one project will simply not create highly reusable content, even if you add supposedly smart software to support them. You cannot easily package the work of teachers as lego-like objects. You can’t. Now, don’t get me wrong. Not everyone working on Learning Objects was mislead. People like Stephen Downes, while he may be disappointed, were not mislead by vague intuitions. Maybe the fact that Stephen is a Perl hacker has a lot to do with realism and vision. I hate Perl for its lack of readability, but I respect it and its hackers.
Become hackers if you are interested in Information Technology. Build your own software from scratch. It may sound tedious, it may sound like a waste of time, but you’ll get to understand many things that you can’t convey in textbooks and articles. Programming is an art, not a form of engineering. This may sound controversial, but Donald Knuth called his books the Art of Computer Programming and Paul Graham called his book Hackers and Painters.