Tuesday I had scheduled for peer design reviews. Let me tell you a bit about how the course works, so that this all makes sense. The three meaty assignments of the course ask students to 1) implement user processes (fork, exec, and a handful of other useful system calls, etc), 2) add virtual memory, and 3) make a simple file system recoverable by adding logging to it. The students work in pairs and are left to both design and implement solutions themselves. We ask them to first submit a design document. The teaching fellows review the design documents carefully and then interview each team, giving useful advice, pushing them on how much they have really thought about what they need to do, clarifying any misunderstandings, and otherwise acting a bit like a project manager.
Historically, design documents vary widely in quality. A few are always nicely done, thorough, well thought out, and complete. Many are usually superficial, because the students are still struggling to wrap their heads around what they are supposed to do. TF feedback is invaluable.
So, this year, before handing the designs in to the teaching fellows, we scheduled in-class, peer design reviews. Each team met with one other team and exchanged designs and then spent an hour discussing and questioning each other on the design. The questions and discussions we heard sounded quite good -- people were asking all the right questions and the teams were pushing each other in just the right way.
At the end of the class, one student made a point to say that he thought the class had been incredibly useful. We will be getting the final designs this evening, so I won't know until next week whether this resulted in qualitatively better designs, but I remain optimistic.
But I suppose my real addiction came out Thursday. Since they are now deeply enmeshed in Assignment 2, as part of my contract, I will not ask them to prep before class. In general, I assumed that meant I would return to lecturing, but as I surveyed my notes on various advanced scheduling algorithms, I couldn't quite see me or the class getting excited by a lecture on this stuff. So, I took a risk.
I prepared four presentations on some scheduling algorithms (a Solaris style Multi-level Feedback Queue scheduler, the Linux completely fair scheduler, a BSD-style fairshare scheduler, and a lottery scheduler). Then I created six roles: four engineers, each of which is partial to one of the schedulers, one product manager and one engineering manager. Each role had some "private" information and the roles and information were on pieces of paper stuck in paper cups, 6 to a table. Students formed groups of 6, selected a role from the cup and then spent about an hour in a design discussion. Given their target platform (which only the product manager started out knowing), they had to select a suitable scheduler.
My goal was that rather than having me go through the plusses and minuses of each approach, they would be forced to compare and contrast and figure out when each one was good/bad. Then each team presented their target platform and their selection, with justification. We wandered around and answered questions and also assumed some other roles: CEO who has an opinion about everything, but isn't technical, VP of marketing who fundamentally distrusts engineers, and the head of QA who would be responsible for testing their systems.
Once again, it's difficult to tell, but my sense is that they covered the important points and each has a deeper, more gut-level understanding of the various approaches. Only time will tell!
This is fascinating! I suspect not only are the students in the class far more engaged, but they're learning on a more profound basis. I'd love to know what the people serving as CEO and VP of Marketing thought of the roles. The good news is that they saved $180,000 in business school tuition and fees to move directly to those positions!
ReplyDelete