Regular readers will remember that in Spring 2010, I taught a Human-Computer Interaction class (CS345/545) in which students worked in teams to develop Android applications. The inspirational goal—stated at the start of the semester and mentioned many times during—was to release novel applications on the Android Market. Out of seven teams, none actually released their applications on the Market during the semester, and in fact, many did not exhibit core functionality by the end of the 15 weeks of development. One team did add some spit-and-polish over the Summer and has since published theirs: it's called Elemental: Periodic Table, and it has 1/2 star more than my own Connect the Dots. (I think there's a good reason for that, and it has to do with expectations management, but I'll write about it another day.)
There is a significant contrast between CS345/545 and the current CS315 course (game programming, a.k.a. 3:15 Studio). This has been kicking around the back of my head for a while, but I have not done any real rigorous reflection about it. However, this is all just set-up for the story, so let me carry on.
I was in the lab the other day with some of 3:15 Studio, and things were going well. I turned to one of my students who was also in CS345/545, and I mentioned that I wished that the Android development had been as productive. This particular fellow is a good student, but it's fair to say that his project tanked last Spring. His response to me was not one of regret or criticism, but rather, he observed that it was better to fail at a big team-based semester project last Spring than to fail at the Morgan's Raid project or his senior capstone.
What phenomenal wisdom! In my own idealistic and individual analysis, I had been thinking about the failure as being a problem that needed to be solved. This student recognized that the learning still happened. Specifically, it was learning from failure, which might be the only kind of learning that matters.
