TITLE: Project-Based Computer Science Education AUTHOR: Eugene Wallingford DATE: October 18, 2007 8:40 AM DESC: ----- BODY: [Update: 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 Bloom filters project. Michael Mitzenmacher has written about programming in algorithms courses in his blog My Biased Coin.) 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 improving undergraduate computer science education. 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
a tiny piece of a big problem, not a small problem to solve by themselves.
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. Whatever order 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. And they have to produce a system that satisfies a need. Greenspun makes several claims with which I largely agree. One is this:
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.
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.
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.
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 problems that matter, 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 Problem Based Learning in Computer Science 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:
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.
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. -----