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.
Collateral-learning is generally not a bad thing - it's awesome when we learn from nearly-every situation.
ReplyDeleteLearning-from-failure is a dangerous phrase that can be used to con one's self into a cycle of taking on future failures in the name of learning.
...
If the goal of producing a product is to remain, then one cannot just revise their analysis of success, they must revise the situation (ex: project) in order to succeed. (This is where there's a huge draw to add more silver bullets intead of reducing the actual risk - which is often the project extent ... especially since having a new-silver-bullet allows one to re-apply the learning-from-failure claim ... even when the silver-bullet does not actually kill the omnipresent Jabberwocky).
...
Speaking from side-experience, of course... ;)
I think I get what you mean here, Jaek, but I think it's important to see the contrast in the experiences. In 345/545, there was no client partner, no third party to whom the students were accountable. The project could be considered one of building a prototype in hopes of landing a contract, and in the end, this guy's team would not have won the contract. In business, that would be bad, but since it was insulated in the "safe fail" environment, there were no negative long-term consequences. Instead, the students (or at least this one) were able to frame it as a positive learning experience despite the overt failure.
ReplyDeleteIn contrast, the Morgan's Raid project has a real audience, and the senior capstone involves client partners external to the university. If this student is able to leverage his experience from 345/545 to promote success in these other endeavors, I'd call that a big win for the university experience.