MOOCs vs. "real" courses

Having completed my first MOOC, I would like to reflect upon the differences between my MOOC experience and the Computer Science courses I teach at Hendrix College.

The greatest strength of the MOOC is asynchrony.  You can watch the lecture where you want, when you want, and even get instant feedback on your work.  There is no limit on class size or enrollment.  There is no need for a time turner to enroll in multiple courses that are scheduled on top of each other.

So what do my synchronous, class-time-intensive courses have to offer in comparison?  The most important thing is pedagogy for topics that cannot be interactively taught by a computer program.  Whether it is a class discussion on the finer points of a proof in an Algorithms course or an analysis of a requirements document in a Software Engineering course, the fact is that much of the material in the computing discipline is not amenable to the MOOC treatment.

Furthermore, much of the feedback a student requires for individual work is also not readily communicable in the MOOC manner, which relies upon being able to program a computer to give the proper feedback.  In other words, as long as artifacts of Artificial Intelligence cannot pass the Turing Test, there are core elements of computing that will require a human teacher.  Here are a few examples:

• Writing proofs of correctness and asymptotic complexity
• Writing requirements documents and specifications
• Writing properly structured, well-engineered code
• Developing solutions to free-form projects

In all of these cases, we have vaguely defined problems that admit a multitude of solutions.  As the problems are vague, so too is the problem of assessing the solutions.  In fact, this assessment is best seen as an interactive process, not a one-time decision.  A good instructor can examine a code submission, give the student feedback, and later review the resubmitted version.  The cycle can continue until the code is satisfactory.

It is indeed noteworthy that most of the items in the above list begin with the word "writing".  It is the development of the ability to communicate a technical solution to another human being with a need that can be met computationally that distinguishes the successful computer scientist.  To develop this ability requires a human coach.  That is how I see myself as a college instructor.  I structure every single one of my courses around the goal of helping my students develop this capacity.  This affects everything from my use of class time to the types of assignments I create and the type of feedback I give when grading.  

So having made these observations, what might the role of MOOCs be in a liberal arts college?  Computing programs at small colleges are often limited in the electives they are able to offer.  It is easy to imagine running an independent-study course in which the student works through a MOOC under the supervision of the instructor.  By augmenting the MOOC with some open-ended project assignments, something closer to a real course experience can be developed.  

But there are some important caveats to note.  First, a MOOC does not necessarily cover content equivalent to a full course. In some situations, creating a proper experience might require more than one MOOC, or perhaps a MOOC in combination with a substantial amount of extra material.  Second, this is not a basis for planning a curriculum, any more than independent study courses would already be employed in such a manner.  To their credit, Udacity has made their courses available under a Creative Commons license. In principle, a useful MOOC could be archived by an institution, in case for whatever reason Udacity in the future does not maintain its availability.  Nevertheless, there is much reason to be wary of MOOCs as being an ephemeral resource.

Much early commentary on MOOCs focused on the possibility of the elimination of the university as we know it.  Thrun himself suggested that in 50 years, there might be as few as 10 institutions delivering higher education.  This particular bit of hysteria is calming down, as reality sets in.  Creating a MOOC has cost the University of Pennsylvania about $50,000 per course.  From my own experience, it is clear that this is not a static investment.  Even a top-flight MOOC is subject to plenty of bugs and problems, and I suspect revisions and updates will be a significant long-term cost.

In any event, it is noteworthy that Thrun himself has walked away from his earlier rhetoric, emphasizing that "...human contact and mentoring make a substantial difference in learning outcomes."  Contact with the right humans is what makes higher education expensive.  It is reasonable to expect cost savings to be modest at best.

I believe this first generation of the MOOC phenomenon has been very valuable.  Many of the MOOCs (especially from Udacity) are terrific resources for learning.  But much of the value comes from forcing those of us in brick-and-mortar institutions to clarify, both for ourselves and for our students, what precise value we add with our (expensive) human presence.  I hope this little essay has made at least a modest contribution in this direction.

Review: Udacity CS 373, Artificial Intelligence for Robotics

Introduction
Having worked in the area of robotics while in graduate school, I was once fairly up-to-date on the latest ideas in the field.  However, I never studied the probabilistic robotics ideas of Sebastian Thrun (which were first published during my graduate school years), although I was vaguely familiar with what he was doing.  The MOOC CS 373, Artificial Intelligence for Robotics, provided me with an opportunity to rectify this gap in my knowledge.  I completed the course over a period of several months.

Format
As with most of Udacity's offerings, straight lecture segments run for a maximum of three to four minutes.  In a conventional classroom, a student is part of a captive audience.  With a MOOC, I found that even 30 seconds of boredom resulted in my opening of new tabs on my browser to seek something more interesting.  So this particular maximum duration strikes me as a savvy move.  Some segments are as short as a minute.  Each segment culminates in some kind of interactive activity.  In some cases, this involves thinking for a moment and answering a multiple-choice question.  In other cases, the student must write or modify a computer program (in Python).

The course is divided into six units:

• Localization and review of probability theory
• Kalman Filters for tracking
• Particle Filters for localization
• Path Planning with A* and Dynamic Programming
• PID Control
• GRAPHSLAM

Each unit consists of a series of interleaved lectures and exercises, ending with a "problem set".  After the last unit is a "final exam".  

As I watched the lectures, I actively took notes.  It was often really helpful to re-wind the lectures multiple times to clarify an obscure or confusing point.  Although it is possible in Udacity's environment to do all of the programming within the web browser, I always made a local copy of the code on my own machine.  This was especially helpful for keeping the code around for future reference.

Strengths
In general, the presentations were lucid and clear.  I have already begun implementing particle filters on my Lego Mindstorms NXT robots.  I am also looking forward to finding opportunities to implement a PID controller and to use GraphSlam.  I found this course to be much easier to follow than Thrun's book Probabilistic Robotics.  This course and that book work well together, actually, because the course provides great context for understanding what he is trying to do in the book.

I found the particle filter, PID controller, and GraphSlam lessons to be particularly effective in slowly building up the material in a comprehensible way.  Especially in GraphSlam, the transition from 1D to 2D and from offline to online was quite effective.

Weaknesses
One of the goals of the course is to employ Bayes Rule as a unifying concept among the various probabilistic techniques.  The effectiveness of this strategy diminished as the course continued.  By the time we got to GraphSlam, the relationship back to the Bayesian foundation was not at all clear.

Related to this is the explicit aversion to explaining derivations in the lectures.  On one level, this is entirely comprehensible; for many students, such things are merely a distraction.  On the other hand, much of the content felt superficial and arbitrary.  A great option would be to have bonus lectures outside of the main sequence containing a deeper overview of the derivations.

The code itself was often put together rather casually.  For example, the 2D GraphSlam exercise requires us to take noise into account.  I neglected to do this in my solution, and it worked perfectly!  The reason it worked is that the motion noise and measurement noise were equivalent.  If they had been set to different values, students would not be able to get away with ignoring the noise as I had.

Another problem with the code is the degree to which good software engineering practices are not modeled well for the students.  Global variables abound, and are often freely intermixed with parameters inside of function definitions.

The use of Python is not always idiomatic; many of my implementations were much shorter than those presented.  List comprehensions, for example, can eliminate many multi-line loops.

The Twiddle exercises were particularly weak.  The second one, in which the instructor confesses not actually having solved it, was especially annoying.

My biggest disappointment with the course, however, was the lack of coverage of essential material. In particular, how does one identify a landmark for use in GraphSlam from sensor data?  The glib answers in the Q&A betrayed this gap.  "Use RANSAC."  "Create local 5x5 meter maps."  "Invert omega to get the covariance matrix." These questions suggest that the course ended too quickly and abruptly.  It is interesting how, on the one hand, a 14-week course is derided as an arbitrary length, but on the other hand, this course is cut off at six weeks while neglecting a critical part of the material necessary for programming a robot.

Another nice extension would be to incorporate FastSlam into the course.  This would build nicely off the excellent coverage of particle filters in Unit 3.  I would love to see some lectures inviting a comparison and contrast between the two SLAM methods.

Conclusion
I enjoyed this course, and given my goals it was a good use of my time, in spite of the flaws I described above.

It is really hard for me to call this a "course".  It does not map well to what I do in a semester of teaching.  I definitely cover a lot more material (both in lecture and in assignments).  But it is a great collection of lectures.

In a follow-up post, I give my thoughts on how MOOCs relate more specifically to the experience at a liberal arts college.