TITLE: Project-Based Computer Science Education
AUTHOR: Eugene Wallingford
DATE: October 18, 2007  8:40 AM
DESC: 
-----
BODY:
[<STRONG>Update:</STRONG>  I found the link to Michael
Mitzenmacher's blog post on programming in theory courses
and added it below.]

A couple of days ago, a student in my compilers course was
in my office discussing his team's parser project.  He was
clearly engaged in the challenges that they had faced, and
he explained a few of the design decisions they had made,
some of which he was proud of and some of which he was less
thrilled with.  In the course of conversation, he said that
he prefers project courses because he learns best when he
gets into the trenches and builds a system.  He contrasted
this to his algorithms course, which he enjoyed but which
left him with a nagging sense of incompleteness -- because
they never wrote programs.

(One can, of course, ask students to program in an algorithms
course.  In my undergraduate algorithms, usually half of the
homework involves programming.  My recent favorite has been a
<A HREF="http://www.perl.com/pub/a/2004/04/08/bloom_filters.html">
   Bloom filters</A>
project.  Michael Mitzenmacher has written about programming
in algorithms courses in his blog
<A HREF="http://mybiasedcoin.blogspot.com/2007/06/what-were-doing-wrong-programming-in.html">
   My Biased Coin</A>.)

I have long been a fan of "big project" courses, and have
taught several different ones, among them intelligent systems,
agile software development, and recently compilers.  So it
was with great interest I read (finally) Philip Greenspun's
notes on
<A HREF="http://blogs.law.harvard.edu/philg/2007/08/23/improving-undergraduate-computer-science-education/">
   improving undergraduate computer science education</A>.
Greenspun has always espoused a pragmatic and irreverent
view of university education, and this piece is no different.
With an eye to the fact that a great many (most?) of our
students get jobs as professional software developers, he
sums up one of traditional CS education's biggest weaknesses
in a single thought:  We tend to give our students

<BLOCKQUOTE><EM>
a tiny piece of a big problem, not a small problem to solve
by themselves.
</EM></BLOCKQUOTE>

This is one of the things that makes most courses on compilers
-- one of the classic courses in the CS curriculum -- so
wonderful.  We usually give students a whole problem, albeit a
small problem, not part of a big one.
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-10.html#e2007-10-13T18_01_08.htm">
   Whatever order</A>
we present the phases of the compiler, we present them all,
and students build them all.  And they build them as part
of a single system, capable of compiling a complete language.
We simplify the problem by choosing (or designing) a smallish
source language, and sometimes by selecting a smallish target
machine.  But if we choose the right source and target
languages, students must still grapple with ambiguity in the
grammar.  They must still grapple with design choices for
which there is no clear answer.  <EM>And</EM> they have to
produce a system that satisfies a need.

Greenspun makes several claims with which I largely agree.
One is this:

<BLOCKQUOTE><EM>
Engineers learn by doing progressively larger projects,
not by doing what they're told in one-week homework assignments
or doing small pieces of a big project.
</EM></BLOCKQUOTE>

Assigning lots of well-defined homework problems is a good
way to graduate students who are really good at solving
well-defined homework problems.  The ones who can't learn
this skill change majors -- even if they would make good
software developers.

Here is another Greenspun claim.  I think that it is likely
even more controversial among CS faculty.

<BLOCKQUOTE><EM>
Everything that is part of a bachelor's in CS can be taught
as part of a project that has all phases of the engineering
cycle, e.g., teach physics and calculus by assigning students
to build a flight simulator.
</EM></BLOCKQUOTE>

Many will disagree.  I agree with Greenspun, but to act on
this idea would, as Greenspun knows, require a massive change
in how most university CS departments -- and faculty -- operate.

This idea of building all courses around projects is similar
to an idea I have written about many times here, the value of
teaching CS in the context of
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-03.html#e2005-03-14T14_47_54.htm">
   problems that matter</A>,
both to students and to the world.  One could teach in the
context of a problem domain that requires computing without
designing either the course or the entire curriculum around
a sequence of increasingly larger projects.  But I think the
two ideas have more in common than they differ, and problem-based
instruction will probably benefit from considering projects
as the centerpiece of its courses.  I look forward to
following the progress of Owen Astrachan's
<A HREF="http://www.compscipbl.com/">
   Problem Based Learning in Computer Science</A>
initiative to see what role projects will play in its results.
Owen is a pragmatic guy, so I expect that some valuable
pragmatic ideas will come out of it.

Finally, I think students and employers alike will agree with
Greenspun's final conclusion:

<BLOCKQUOTE><EM>
A student who graduates with a portfolio of 10 systems, each
of which he or she understands completely and can show off
the documentation as well as the function (on the Web or on
the student's laptop), is a student who will get a software
development job.
</EM></BLOCKQUOTE>

Again, a curriculum that requires students to build such a
portfolio will look quite different from most CS curricula
these days.  It will also require big changes in how CS
faculty teach almost every topic.

Do read Greenspun's article.  He is thought-provoking, as
always.  And read the comments; they contain some interesting
claims, too, including the suggestion that we redesign CS
education as professional graduate degree program along the
lines of medicine.
-----