Theory and Practice

My first trip through grad school was in English, and my primary focus was literary theory. My second trip through was in educational technology. I enjoy theory and philosophy more than your average bear, but my approach to training development has always been a pragmatic, from-the-ground-up affair. I have a general distrust of buzzword-compliant theoretical discussions of instructional design. There’s a vast difference between talking about instructional media and producing it. And it is the production of it that has always been my best teacher.

This doesn’t mean theory has no role to play. Theory can guide practice, just as feedback from the trenches can guide theory. But, since talking about the proper design of instructional media takes so little effort, compared to actually creating any of it, there tends to always be a surplus of theorizing in the weird little world of educational technology. My words here are complicit in this surplus. Pontificating about instructional design is easier than learning Objective-C, which is what I should be working on right now.

Take, for example, the ardent defenders of certain cherished instructional design models, like ADDIE, which is short for Analysis Design Development Implementation and Evaluation. It is a generic model for training development and one deeply cherished by many instructional designers. Its origins are shrouded in mystery, but it dates at least to the mid 1970s, possibly much earlier. The main (and, I maintain, legitimate) criticisms of it focus on it’s linearity. In its most basic form, each stage is discrete and must be completed before the next stage can begin. There are more flexible ways of implementing it, of course, but the very fact that its name is a mnemonic device for remembering the sequence of the steps in its design process should be some indication that these criticisms are not without merit. It is a “waterfall” model, and all waterfall models suffer from these sorts of criticisms.

ADDIE also suffers from the fact that, like other waterfall models, it encourages what is sometimes called ‘big-design-up-front.” The idea is that a through a priori analysis can best identify problems in advance, where they are less costly to fix. There are some strengths to this idea. Many creative folks eschew planning, seeing it as a bound on their creativity (which it, of course, is, though that is part of the point). And the folks who excel at project management aren’t, generally, the same folks who create the solutions. They have their sort of creativity, to be sure. But they play a role similar to that of movie producers. Their job is to keep things on schedule and on budget. They also wear ties. I think they actually enjoy wearing ties.

Going boldly forward without a plan sounds romantic, but it can often end tragically. There’s real time to be saved by employing some basic project management principles to instructional design projects. The problem, of course, is that anticipating every problem up front isn’t possible. Shortcomings in the vision of a project, unforeseen technical issues, and bad design decisions often only become clear at the point of implementation and evaluation. Some versions of the ADDIE idea recognize this limitation and attempt to include feedback and evaluation into the early stages as well as the later ones. The irony, of course, is that all of this up-front planning, in an effort to avoid potentially expensive pitfalls latter on, take quite a lot of time and money to do.

Instructional design, and education in general, has always drawn on other disciplines. I wish it would draw more on software development methodologies, which have, for the most part, moved past these strict, linear models and into more flexible, iterative strategies involving multiple loops of rapid prototyping and feedback. (An umbrella term for many of these approaches is RAD, which is short for Rapid Application Development.) A lot of what instructional media designers create these days is, in fact, software. So why shouldn’t the development of it be guided by similar principles? I think it clearly should, at least for those who would rather develop solutions than talk about them.