Drinking my own lemonade

In a previous post on 12/5/2005, I commented on one impact of lower CS enrollment: smaller classes. I was wondering what I would do differently in my Winter quarter class, given that there would only be a few students in it. Now that the quarter is over, I thought I'd comment on what actually happened.

The class in question was a combination of algorithms, discrete math, and object-oriented design and programming. I ended up with 8 students in the class. Instead of meeting in the regularly scheduled classroom, we met in my lab, which gave a cozier, more group-oriented atmosphere. I organized the class around a single project. I covered all of the material that I would normally have, but started each topic with a roughly 30 minute presentation given by each student.

Project

I initially left the project wide open to student input; I would have been perfectly happy with any project they proposed, as long as it exercised the various topics we needed to cover. Failing that, I proposed what eventually turned out to be a simplified version of del.icio.us, except using hash tables, AVL trees, red/black trees, and graphs -- instead of databases -- for the back end. The project eventually developed an architecture with a back-end server (the bulk of the project) responding to CGI application requests. It actually is quite a nice job; I'm just waiting for a couple students to finish a "story of the project" web page (which I indicated was beyond the scope of the course itself) before making the URL public (just for looking; I won't leave the server running).

Project management

I am by nature a pretty hands-off person. It was not my goal to micro-manage the project, and in fact I would have been happy to have the students do everything. However, I couldn't make that a requirement of the course, as it wasn't a project management course. Instead, I gave them a lot of leeway, and if they didn't take up the slack, I gradually tightened things up and prescribed what they would do. So, at first things were wide open, even including the project itself. Then, I specified the overall project goal. I later led an in-class design exercise, and broke the project down into subsystems and tasks and farmed them out to teams. So, step by step, I produced more specific directions on what would be done, by whom, and when. Eventually, we had all of the elements you'd expect of a project: milestones, interface documents, version control, team meetings, group meetings, weekly reports (with required reflection on successes, failures, what they were doing right and wrong, and what they'd do differently the following week), code reviews, etc.

Certainly, I could have done all of this from the start -- it's how programming assignments would normally be done in CS classes -- and more could have been accomplished. but I think there's value in students being given a chance to do something, see that one approach doesn't make much headway, and then see that an alternative given by me works. I think, as long as you don't allow things to get too chaotic or students to get discouraged, this is better than laying everything out at the start. We were still able to accomplish all of my essential goals, and that's all one can really hope for in one quarter (did I mention yet that the quarter system sucks?).

Presentations

I developed a rubric for grading student presentations and summarized it in my syllabus. These are undergraduate presentations, and so they of course can't be expected to be up to the level of presentations in a graduate seminar. Beyond the experience itself, it helped to give me clues regarding what topics to cover in more detail.

All in all, I was pretty happy with the class' results. I'm not sure I would recommend this approach in a class with more than eight students. I suppose there could be multiple, smaller groups, but how crazed would it be to have multiple, large (all quarter or semester long) projects ongoing? Generally, I don't like group projects (I do one in a class every so often to remind myself why I don't like them), but the length of this one and the number of students helped mitigate many of the negative issues.

Take home message: size does matter. Smaller classes are better.

Topics: academia, computer science.

[+/-] show/hide the rest of this post