Friday, March 20, 2009

Class Projects

For some reason, class projects are all the rage in graduate classes here at the U. These are typically used in lieu of a final, and generally involve (for most classes) some kind of software artifact. Students seem to prefer projects to exams in fact.

When I started designing my graduate classes, I had mixed feelings about class projects, but allowed students (especially in my comp. geometry class) to propose various ideas. Two years in, I still have mixed feelings about class projects.
  • It seems to me that for theory classes, a "pure theory" class project is difficult to execute. Most students here don't have a 'general theory' background, and so it would be well-nigh impossible for them to execute a class project of the form 'here's an open problem: go attack it'.
  • A cop-out option is a survey paper on an area. Now in principle survey papers can be an excellent way of distilling the knowledge in an area, organizing it, and then presenting it. But in practice, a survey ends up looking like a sequence of paper summaries, with little to no higher-level organizing
  • For some classes (geometry, specifically) a software artifact can make sense. In that regard, having CGAL around is handy because a lot of low-level grunt coding gets taken care of. But invariably the software artifact degenerates into a horse-race for a bunch of techniques, or "let me implement my research project that I'm working on somewhere else, and slap some O() notation on it to make it look like a CG project".
The problem a class project (ideally) is trying to solve is providing an avenue to synthesize and apply the concepts being learned in class in some kind of holistic way. But I'm unconvinced that the class projects people are actually doing are effective in that regard. Incidentally, since some of my complaining has to do with topic choice, I should add that I've often given out topics for people to look at: no one likes my topics though :).

I teach the grad intro algorithms class in the fall, and am tempted to do a class project where I require students to do some actual algorithmic modelling drawn from their home area (most students taking this class are not algorithms folk): which is to say, take a "real problem", and analyze it as an algorithms person would if given the problem by an applied researcher - formalize, prove hardness, come up with algorithms, repeat, ....

If it weren't such a pain to design finals that aren't solvable via Google, I'd probably never use projects at all.


  1. One immediate attraction of projects is the "I can get around to this whenever" reasoning, as opposed to "I have to free up one weekend."

    Beyond that, I would bet that part of the problem is time. I think the problem may be if you give free rein to pick a topic, they're not going to go far from what they're already working on for another class or their own research. I know that I'm often tempted to do this because of my own time constraints.

  2. As a student, what I really liked about class projects was actually none of the items you listed. I liked them because they gave me an excuse to try something crazy that probably wouldn't work (and almost never did) but that I wouldn't have really found time to try otherwise. (I.e., I did not follow the model of "just continue working on your own research.") I never had projects in anything that looked remotely like a theory class, though!

    As a teacher, I had open class projects the first class I taught and never again. Every semester I consider reintroducing it, but don't (I thinking about it for this coming Fall now!). Here are a few reasons why: (1) Grading is a nightmare because nothing is comparable -- this matters a lot if you have any undergrads or MS students who still care about grades. (2) Do you have them present in class? If so, there are 4 class periods down the drain; if not, it's a bit anti-climactic and presenting is a valuable skill. (3) people who already use techniques in their research like what you each (in my case, machine learning) have a really easy time (eg., in my case, web mining folks) and people who don't really have a disadvantage (eg., systems folks). Yet it is really the latter audience that I want to reach! (4) Esp with people who already use some of your technology, it's really hard to tell if they actually used anything they learned in class from the project, or if they just continued to blindly apply things that were in vogue in their community.

    I'm actually a bit intrigued by your idea of "think like an algorithms person" on this problem, but I'd worry that they'd pick the most obviously algorithmic open question in their area, even if it's not that interesting. (Somewhat like (4) above.)

    Another option that I've seen done in small classes (5-15 people) is to have a single unified project that everyone works on. In the cases I know of, this has always led to a 5-15 author paper, but I worry that on the high end of 15, it's too much organizational overhead. Importantly, it's something that you -- as the teacher -- pick ahead of time that's a project that can be easily distributed. Might be hard in theory.

  3. Suresh --

    I avoid projects in my "pure theory" grad class, but I do use them in my "applied theory" class (which I'm teaching this semester -- anyone have good project ideas??). I agree that it's extremely difficult to do a project in a theory-oriented class, where you don't have a clear path to finishing -- although it's also difficult in other classes as well!

    To me, the primary bottleneck is finding good problems. I tell students to think of the project as a first step to an eventual publication. And the hardest step is always finding a problem you think you can make headway on (that are actually interesting). I think it's very frustrating for students -- but since they're mostly early grad students or undergrads heading that way, it's a frustration they'll have to get used to.

  4. I used projects when I was at UBC, but the graphics and systems folks at UNC use projects so heavily that I front load my computational geometry course, and assign hard homework during the first couple of months instead. That gets students working together early, which is how it should be.

  5. I agree. For intro to algorithms, have you considered just asking your students to implement something that is a 'fast' algorithm, (runs in linear time), but is just hella crazy to implement, like graph planarity?


Disqus for The Geomblog