If you're not in the US college/university system, for clarification purposes, a "senior" is someone who is in their fourth and final year while a "junior" is someone in their third year. Got it? Let's go…
On 02 May, I had the opportunity to return to my alma mater – Rose-Hulman – and speak to a class on Software QA. It was a great opportunity and discussion spurred by (hopefully funny) war stories and major screwups that I was more than happy to share.
The most interesting aspect that I saw was the injection of strong Project Management techniques into the curriculum. I don't just mean "here's a deadline… go!". I mean real specification writing, task estimates, milestones, code reviews, deliverables, QA, and overall management. In fact, they get a bit creative in how they do it and even study things such as team psychology and touch on Meyers Brigg. Whoa.
But then they tie it back to the core curriculum…
Part of the fear of every Rose student is their Senior Design Project. Most Senior Design Projects span the entire year, are for real-world companies, are worth 10-12 credit hours (out of 48) and are basically a make or break deal. The way the graduation credits work out… if you don't pass your project, you could feasibly come back for another year.
So how do these fit together?
In order to prepare the students for their upcoming Design Project, Rose starts pounding on them early. All of Junior year is dedicated to putting the pieces in place… such as teaching Code Reviews. So where do they get the code? From the seniors!
Each Senior Design Project gets a set of Juniors attached to them. The Juniors provide support and an additional set of eyes into the project while they get a view into the Senior Design Projects before they have to dive into them. It's a win-win for both sides.
The more interesting part is that it puts some friendly cooperation and peer pressure in place. They've managed to turn both groups into project stakeholders who want and need to find the issues early and while they're as fixable as possible. Failure to do so makes both groups suffer… One anonymous commentor summed it up this way:
The main metaphor that I will remember was that of titanic bugs. This concept is to notice issues weeks beforehand in order to fix them, rather than just days before release when there isn’t much that can be done.
As horribly biased as I am towards Rose-Hulman, it's still good to see somewhere that gets it.
I also wrote about this presentation on the WhyGoSolo Blog.