- 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?).
- 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.
Take home message: size does matter. Smaller classes are better.