TITLE: Death by Risk Aversion, University Edition AUTHOR: Eugene Wallingford DATE: February 16, 2006 4:18 PM DESC: ----- BODY: Death by risk aversion, courtesy of Creating Passionate Users In When Committees Suck the Life Out of Great Ideas, Jeremy Zawodny wrote:
A few days ago, I saw a nice graphic on the Creating Passionate Users blog which was intended to illustrate Death by risk-aversion: [at right] I contend that you can make a very similar graphic to illustrate what happens when too many people get involved in designing a product.
I saw that blog entry, too, but my first thought wasn't of software products and committees. It was of academic curriculum. I have mentioned this post on academic conservatism so often that I probably sound like a broken record, but real change in how we teach computer science courses is hard to effect at most schools. This difficulty stems in large part from the "fear occurs here" syndrome that Kathy Sierra identifies and Jeremy Zawodny recognizes in product development. Faculties are understandably reluctant to change what they've always done, especially if in their own minds things are going pretty well. Unfortunately, that comfort often results from a lack of circumspection... Maybe things aren't going as well as they always have, and we might see that if we'd only pay more attention to the signals our students are sending. Maybe things are going fine, but the world around us has changed and so we are solving a problem that no longer exists while the real problem sits ingloriously at the back of the room. The result of the "fear occurs here" syndrome is that we keep doing the same old, same old, while opportunities to get better drift by -- and, sometimes, while some competitor sneaks in and eats our lunch. The world rarely stays the same for very long. There are always folks who push the boundaries, trying new things, working them out, and sharing the results with the rest of us. The annual SIGCSE conference and Educators Symposium at OOPSLA are places I can reliably learn from teachers who are trying new ideas. And there are many... Stephen Edwards on testing early in the curriculum, Mark Guzdial on multimedia programming in CS1, Owen Astrachan on just about anything. I would love to see my own department consider Mark's media computation approach in CS1. Short of that, I plan to consider something like Owen's science-of-networks approach for next fall. (You can see the SIGCSE 2006 paper on the latter via the conference's on-line program. Go to Saturday, 8:30 AM, and follow the "Recruitment and Retention" link.) Indeed, I am looking forward to SIGCSE in a couple of weeks. But I've also had ChiliPLoP'06 on my mind, too. I am co-chairing ChiliPLoP again this year, and we have two relevant hot topics on topic: a reprise of last year's elementary patterns project and Dave West and Pam Rostal expanding on their OOPSLA Educators Symposium presentation to a software development curriculum using pedagogical and apprenticeship patterns. But these ideas are emblematic of how hard it is to effect real change in curriculum: it is hard to do a complete job, at least complete enough to attract a large body of adopters, and some ideas are simply so unlike anything that people currently do as to be unthinkable by the vast majority of practitioners. We know that revolutionary change can happen, with the right group of people leading people, working hard and having a little luck along the way. But such revolutions are a low-probability proposition. [As an aside... After reading this article on productivity patterns and "life hacks" over at 43 Folders, I boldly sent site guru Merlin Mann a flyer of an invitation to consider coming to ChiliPLoP some time to work on a productivity pattern language with his GTD buddies and a few patterns people. Productivity patterns don't fit the narrow definition of Pattern Languages of Programs, but ChiliPLoP has always been about pattern languages more broadly. Besides, I'd love to swap Mac hacks with a few more fellow junkies.] -----