Archive
T Minus 17 Hours
In a little less than 17 hours, 48 students from 14 different universities will be starting a 3-day code sprint here at the University of Toronto. Their workrooms are locked down, their network is waiting for them, pizza has been ordered—I’m psyched, and really looking forward to working with them.
Presentation, Presentation, Presentation
Over on the Software Carpentry blog, I’ve posted a plea for pointers to good online tutorials: if I’m going to reorganize the SC material, I’d like to upgrade the format as well, and I’m looking for pointers to stuff that’s effective, but (relatively) easy to produce.
And sticking to our presentation theme, I’m talking at Stackoverflow DevDays on Friday, October 23. Here’s what I think I’m going to say (and yes, thank you, it does bear more than a passing resemblance to the book I’m editing for O’Reilly):
Bits of Evidence: What We Actually Know About Software Development, and Why We Believe It’s True
By the time the Seven Years War ended in 1763, Britain had lost 1512 sailors in action, but almost 100,000 to scurvy—despite the fact that the Scottish surgeon James Lind had shown twenty years earlier that a little lemon juice every day was enough to prevent or cure the dreaded ailment. It was more than a century before medical practitioners began paying attention to controlled trials of this kind: as recently as the 1950s, many doctors rejected statistical results linking smoking to cancer, saying that what happened “on average” was of no help when they were faced with a specific patient. Today, though, most practitioners accepted that decisions about the care of individual patients should be based on conscientious, explicit, and judicious use of current best evidence.
The idea that claims about software development practices should be based on evidence is still foreign to software developers, who often talk as if a beer and an anecdote constituted proof. This is finally starting to change: any academic who claims that a particular tool or practice makes software development faster, cheaper, or more reliable is now expected to back up that claim with some sort of empirical study. Such studies are difficult to do well, but hundreds have now been published covering almost every aspect of software development. This talk will look at some of the best of those studies, which are as elegant as classic experiments in physics, psychology, and other scientific disciplines.
Applications and Data Sets
The first homework assignment for students in the Government 2.0 consulting course was to find prior art (i.e., existing applications on the web) and data sets that might inspire them. Here’s what they found:
More Readings for Gov 2.0 Students
- Dan Bricklin (yes, the Dan Bricklin) thinks aloud about Microsoft Natal, Google Wave, and the future of—well, of lots of things.
- Vancouver’s Open Data Catalog: they’d like your feedback on what you want and how you’d use it.
- David Eaves thinks garbage collection is sexy.
- Monday, October 26, is the Toronto Not-for-Profit Open Source Expo. You want a project? Contact its organizers and ask them to introduce you to someone who needs your help.
- The Government 2.0 Club. No, really…
Health Dashboards
Good post from John Halamka with links to healthcare dashboards for various districts in the US:
How often would you check this if it existed for Toronto?
Want to Go to MIT?
Would you like to go to MIT? Or sit in on their first-year programming lectures (which now use Python)? Old news, but now you can: course materials and lecture videos are now online. I’m way behind this curve—some of the early Software Carpentry lectures were videotaped back in 1997, and Paul Lu and I gave some lectures via Skype Video this summer, but that’s it. I’d really like to create a high-quality self-paced over-the-web version of the course, but if what I’ve heard and read is true, an hour of usable material will take 50-100 hours to create. That’s… um… carry the three… pretty much a full working year for one person, which means it’s unlikely to happen. *sigh*
Habit Forming
One of the goals of education is to form habits: to make the best way to do something the automatic way to do it. It turns out that may be harder than we thought. New research indicates that the oft-quoted “21 days” rule is a myth; the real figure is on average in the mid-60s, with some things taking significantly longer.
I think this is bad news for anyone teaching good programming practices at the university level. We don’t have students long enough for things like using debuggers or test-driven development to bed down as habits. What’s worse, their next instructor probably won’t mention them at all (since his or her course is supposed to focus on databases or compilers, how students work just isn’t on the radar), so the reinforcement needed to make good practice automatic isn’t there.
Newer Outline for Software Carpentry
I have updated the description of how I plan/hope to reorganize the Software Carpentry course. My thanks to everyone who commented on the earlier draft; I’d be very grateful for feedback on this one as well—I realize that some of the lectures are still hopelessly ambitious, but I hope it’s at least a target to shoot at. Please post comments on the Software Carpentry blog post.
Government 2.0 Treasure Hunt
As I said in a previous post, the students in my Government 2.0 consulting course are doing a treasure hunt this week: each student has to find and describe two existing Government 2.0 applications, and also two interesting data sets. I’m collecting their findings on a new page on this blog—your comments would be very welcome.
Recent Comments