In Fall 2010 I’ll teach my Advanced Embedded Systems course for the fifth time. This is a class that I enjoy teaching and that students generally enjoy taking. I created it from scratch and am fairly proud of it. There’s just one problem: I’m ready to stop giving the lectures. First, although I tweak and improve them each year, I’m getting somewhat bored with them. Second — and much more important — I’ve become convinced that (in this case, not necessarily in general) lectures aren’t the best use of class time. For one thing, even when students are actively engaged with the material, it’s hard for them to sit still and listen to someone for 75 minutes. For another, the thing I really want students to get from the class is a taste of real-world embedded systems design and implementation. They should be learning skills such as working in a team, understanding requirements, evaluating software architectures and other implementation choices, creating maintainable code, debugging in challenging environments, reviewing code, and figuring out how to test complex combinations of hardware and software.
Here’s my idea. First, while giving the lectures this fall, I’ll arrange for good-quality videos to be recorded, so I can put them online. Second, after this fall, I’ll give few or no lectures but rather ask the students to watch at least some of them online, outside of class. Then we’ll spend the class periods — typically two 75-minute sessions per week — working out the design and implementation of a more open-ended and aggressive collection of projects than I had previously given (note that there are 3 hours of lab time per week in addition to the lecture time). Also, after teams get their projects to work, I’ll require them to integrate these projects with each other, for example using a serial line or CAN bus. Previously, when I have required interaction between different teams’ projects, this has turned out to be far more challenging than the students anticipated, even for relatively simple projects such as distributed time synchronization or a consensus protocol. Also, I’d like to spend a fair amount of time in class doing code reviews. It turns out that for a variety of reasons, such as the fact that they always get to throw away code after writing it, a lot of junior/senior-level CS and CE students are not exactly the kind of coders I’d hire for an ambitious embedded project. Regular code reviews can help turn coders into real programmers. One final idea that I keep wanting to try, but haven’t yet, is to force teams to exchange code bases with each other partway through the semester. This is basically evil and will probably cause me to take a hit on the teaching evaluations, but I think it is guaranteed to be a character-building experience.
Anyway, it’s possible that this experiment will make my course more awesome, or it may tank miserably. I’d love to hear feedback and advice from readers, either in the comments here or in email. In a couple years I’ll let you all know how it went.