MOOCs and Engineering

I guess it shouldn’t be surprising that the world of MOOCs seems so bound up with the world of engineering and technology, especially computer science.

After all, the first online classes that went massive to the tune of 100,000+ participants were computer science courses from Stanford, with the teachers of those courses going on to found two of the three major MOOC providers: Udacity and Coursera.

And when Harvard and MIT decided to get into the act in a big way, the person they put in charge of their new edX initiative was both an engineer and a teacher of engineering subjects.  And some of the most popular courses at edX are in the field of – you guessed it – computer science.

Given what it takes to put together the technology needed to deliver online courses to millions of people, it’s really no surprise that the folks who stepped up to deliver this capability possessed both software development talent as well as the engineer’s can-do mindset that sees even the most daunting challenges as just another problem to be solved.  And the fact that we are where we are after less than two years into MOOC history demonstrates that those technical challenges could indeed be solved.

Technology folks like computer programmers are often accused as having an unrealistic attitude of what can and cannot be done.  And while I’ve been in organizations where the difficulty and costs associated with software projects have been grossly underestimated, the best programmers and system designers I’ve worked with were the ones I turned to for reality checks on my schemes and dreams (i.e., they were the folks who could tell me straight that if I wanted A, I couldn’t have – or would have to wait for – B).

But engineers also have a certain way of looking at the world which tends to translate every issue into a problem that can be solved with some update, modification or tweek to “The Platform.”  And having gotten past the 20 mark with regard to MOOC classes I’ve taken (or am taking), I can attest to the fact that there are a number of issues still needing to be worked out that won’t be overcome by throwing technology at them.

For instance, while I’d love to see MOOC platforms provide a wider range of assessment options, most courses are still not making effective use of the capability already built into the underlying technology.  And production values on most courses are still far lower than they need to be, even for institutions looking to create their courses without spending hundreds of thousands of dollars on them.

To a large extent, the strategy of the MOOC companies has been to provide professors a set of tools and let them create courses as they like, without having some programmer breathing down their neck saying what should and should not be included in a class.  And this division of labor between the platform provider and content creator has been both sensible and productive (i.e., it’s the very strategy you’d expect an engineer to come up with as a solution to the problem of how to scale course content).

But “the product” delivered by companies such as Udacity, Coursera and edX are educational in nature, which means that educators across various disciplines will ultimately need to play a bigger role with regard to how “The Platform” continues to develop.

Right now, that relationship is osmotic in that creative things done by one professor inspires changes to various systems that can then be taken advantage of by the next generation of course developers.  But there are fundamental issues of pedagogy that are playing an increasingly important role in the MOOC “movement,” which makes it inevitable that the science-minded folks who got the revolution started will need to clear more space at the table for people whose backgrounds are in non-technical disciplines (a process that is already underway).

Personally, I don’t think we’d be where we are if the can-do attitude of the engineer hadn’t given birth to the MOOC, especially since the other avenue for universities to create things (the inter-departmental committee, broken into subcommittees each charted to stare at a different corner of their own collective navel) is not the structure commonly associated with success (at least with regard to software development).

But now that the rocket is off the launch pad, it’s time for experts in varying fields to take their places on the main deck.  To speak in pure engineering terms, the Star Trek crew needed to include technologists (such as Scotty), content specialists (like Mr. Spock), strategists (Captain Kirk, or course) and gadflies (i.e., Dr. McCoy) to take on the universe.  And getting this mix right tends to be the difference between a successful Enterprise/enterprise and a forgotten one.