This year’s Google Summer of Code students and projects have been posted—congratulations to them all. The list unfortunately doesn’t specify which open source organizations the projects are with, or what schools the students are from, but we’ve had a few successes:
- Mike Conley (University of Toronto, Canada): finishing off ReviewBoard’s extensions framework
- Chas Leichner (University of Arizona, USA): a “guided replay” extension for IDLE (I’m mentoring this one)
- Ian Lienert (University of Toronto, Canada): a naive Bayes algorithm for classifying email in Thunderbird
- Lori Lee (University of Toronto, Canada): phpMyAdmin UI cleanup
- Christian Muise (University of Toronto, Canada): supercharging SymPy with assumptions and logic
- Kevin Salvesen (currently University of Toronto, but heading home to Sweden): improving the reStructured Text WYSIWYG editor
- Sarah Strong (University of Toronto, Canada): making the clipboard work like it’s supposed to
- Felipe Vieira (Federal University of Campina Grande, Brazil): RSS feeds for FreeSeer
My apologies to anyone I missed, and best of luck to everyone involved.
A month ago, I gave myself a mixed performance review for my time at U of T. Turns out a few people think I deserve better: enough to scare the bejesus out of me last night when they all yelled, “Surprise!” It was one of the nicest things anyone has ever done for me, and I’m grateful to everyone for making the end of my time at the university a memory I’ll treasure for the rest of my life. So without further ado, here are the pink hippo cake:
and the plaque listing all the projects my students and I have worked on in the past seven and a half years:
and my daughter, celebrating as only a three-year-old can:
Thank you: Abayomi, Ainsley, Alecia, Amy, Andrew, Aran, Blaaaaaake, Brent, Catherine, Cordelia, both Davids, Delphine, Diane, Dominique, Ellen, Florian, GregL, Clumsy Igor, Irving, Isaac, both James, Jason, Jennifer, Jessica, Jon, Jonathan, Jorge, Justin, Karen, Kristin, Laura, Laurie, Lila, Lilian with one L, Lillian with two L’s, Luis, Madeleine, Maria, Matthew, Michelle, Mike, Miles, Misa, Pat, Rory, Sadie, Sana, Sean, Sukhmeet, Tom, Val, Veronica, Victoria, William, Zuzel, and everyone else who couldn’t be there—thank you all.
Later: so it turns out there’s video as well…
I don’t know who Kurt Grandis is, but I’d like to buy him a beer. From his post:
Almost two years ago I was in a rather unlikely situation in that I was running a software engineering department containing both a C# team and a Python team…It slowly dawned on me that I had a perfect test bed. Here we had two teams using different technology stacks within the same department…they shared the same development processes, project management tools, quality control measures, defect management processes. Everything was the same between these groups except for the technologies. Perfect! So like any good manager I turned my teams into unwitting guinea pigs.
And yes, those velocities are normalized—see the full article for details. A couple of commenters have used his report as an excuse to re-hash the whole “open source is better than Microsoft”, but I think the real story is more interesting: by working and measuring in short chunks, even a small software shop can collect enough data to make decisions with real business impact.
Congratulations to Jason Montojo and Jon Pipitone, who have just completed their Master’s degrees in Computer Science at the University of Toronto. Jon was one of my very first CSC49X students in September 2002, and Jason was in the second batch in January 2003. I’m proud to have worked with them, and wish them all the best.
And in other school news, Alecia Fowler is still looking for people to participate in her web-based study of how people understand maps. If you have a few minutes, and would like to help her help the visually disadvantaged, please send her an email at firstname.lastname@example.org.
(And in other school news, I handed in my final set of marks two days ago. Yee hah!)
The April 2010 issue of Communications of the ACM has an article by Keith Wright titled “Capstone programming Courses Considered Harmful”. Dr. Wright teaches business intelligence courses at the University of Houston-Downtown, and once you get past the three and a half columns of autobiography that he opens with, his thesis is:
- Enrolment in CS programs is down. OK, no problem so far.
- “…a lucrative United States career as a generalist professional programmer [is] a thing of the past” because the jobs are being offshored. Hm… OK, it’s not that clear-cut, but I’m still on side.
- Further, there has been a “…dramatic decline in demand for U.S. programmers over the period from 1974 to 2004.” Uh, what? Oh, there’s a footnote (pg. 126): “Demand for database, ERP, and ecommerce servers skills are on the rise.” I’m confused: does he think that making Oracle, SAP, and WebSphere behave doesn’t count as programming? And even if that’s true, demand for programmers has declined from 1974 to 2004? Crap.
- “When designing computing curriculums, it is useful to first consider the capstone courses.” Not the way I’d do it, but OK.
- I need to break the next paragraph down line by line:
- “Many of today’s capstone courses involve locating real programming projects in the community.” Sure, the good ones.
- “However, this is often too time consuming.” Compared to what? And why does he think it’s any harder for CS than for the engineering schools (most of which have to include a year-long capstone to keep their accreditation)?
- “Furthermore, real projects are usually too difficult for college seniors.” Crap. There are projects of all shapes and sizes out there, from porting Django to Python 3 down to tweaking the web site for a local community group.
- “Other capstone computing courses have students working individually on imaginary projects, giving them a chance to build something they own.” OK.
- “Unfortunately, this may give students a poor understanding of the real world.” Well, sure, if it’s done badly, and the same can be said of any coursework.
- “Finally, we do students a disservice if capstone courses give them the impression they are likely to become professional programmers.” Ah, now we come to it…
That last point is, I think, the hinge of the whole article. Wright thinks that most CS graduates are going to go off and do things that aren’t programming (like, you know, building web applications ‘n’ stuff), and that having them do a big programming project in their final year is therefore misleading. His solution?
I believe part of the answer lies in industry best practices like those captured in the IT Infrastructure Library (ITIL) and the corresponding international standard—ISO 20000. So I suggest…that capstone programming projects be replaced with the following internships:
- Service desk (first-line customer support).
- Change management.
- Programming (good to see this hasn’t been thrown out completely).
- Networking (configuring, diagnosing problems, etc.).
- Problem control (by which he means operating system administration).
- Service level management: “Emphasized would be the writing of ethical service level agreements, underpinning contracts, and operational level agreements.” Yee hah, I can feel my heart pounding faster already.
I find it hard to think of a better way than this to drive bright students away from computer science: if we offered the UCOSP students job training for Fortune 500 IT departments, we wouldn’t have any UCOSP students. Yes, a stint on the help desk is a good reality check, and it’s important for computer scientists to realize how confusing our creations are to the 99.5% of humanity who can’t think recursively. And yes, software engineers should know what a service level contract looks like (preferably an ethical one, whatever that means), but computer science is supposed to be exciting, dammit, and Wright’s vision of computing is about as exciting as a vending machine ham-and-cheese sandwich. Compare his ideas with those of real innovators like David Humphrey (who, by the way, has actually tried his out), and it’s painfully clear who’s looking backward, and who’s going to lead us forward.
James Hague has an interesting series of posts about functional programming, the latest of which, “Functional Programming Doesn’t Work (and what to do about it)” starts with:
Read suddenly and in isolation, this may be easy to misinterpret, so I suggest first reading some past articles which have led to this point.
I agree with his thesis: eliminating mutable state, side effects, and/or global variables doesn’t always make programs cleaner. I’ll know that we have a working theory of program complexity (as opposed to algorithmic complexity) when such recommendations can be prescriptive.