A number of colleagues have pointed me at Joel Spolsky's latest post, Capstone projects and time management. In it, Joel argues for the inclusion of real-world projects in computer science programs and laments the near universal dismissal by (top) schools of any grounding in things like version control, debuggers, testing, etc. He writes:
It is amazing how easy it is to sail through a Computer Science degree from a top university without ever learning the basic tools of software developers, without ever working on a team, and without ever taking a course for which you _don’t _get an automatic F for collaborating. Many CS departments are trapped in the 1980s, teaching the same old curriculum that has by now become completely divorced from the reality of modern software development.
Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation? Where do they learn to write a program longer than 20 lines?
He ends with this interesting observation (emphasis mine):
The only reason the real world gets this right where all-student college teams fail is because in the real world there are managers, who can set deadlines, which a team of students who are all peers can’t pull off.
This echoes another conversation I had on Mozilla's Education irc channel today. Sid, Blake, and I were talking with about the complete lack of version control use among most students:
< sid0> bwinton: I've even tried convincing several people to switch to version control, but I guess zips are "good enough" for the kind of assignments we get (at most a thousand lines or so, 1-2 people)
<humph> sid0: exactly. you have to need it before you need it. they don't need it with that stuff
< sid0> yep, exactly
< bwinton> So, sid0/humph/jcranmer, how would you get people to switch to version control? Just give a really big/long assignment?
< sid0> bwinton: I guess a more productive way would be to get people into open source
<humph> if you want people to learn things like this, you have to insert them in a mature environment that already does this stuff and have them do what the others do. if they do what the others do, and the others are just their peers, they never learn anything new.
You can sum up this conversation and Joel's conclusion by asking a simple, but important question: who are your peers? As a student, with whom do you surround yourself? As a professor, who are the people collaborating with your students? As a developer, manager, or other industry professional, with whom are you (and your employees) engaged on a daily/weekly basis outside your company? Who are your peers?
Joel's solution to this problem is also the same reason Sid knows version control, and uses it as a student studying computer science in India: the only way to learn real-world skills is to engage with the real world, and more specifically, with the problems of the real world. Sid's a professional software developer even though he's still in school because he's taken it upon himself to work on Mozilla development now, and in so doing diversified his peer group to include some of the best software developers in the world. That problem you can solve the night before it's due for class, the one whose code you are swapping back and forth across email with your group members, it's not real. The fact that you can work on it like this, and get away with it, necessarily disqualifies it from any definition of 'real.' It's not real, it's simply due. It's uninspired, unimportant, and unnecessary.
It doesn't have to be this way. Despite Joel's broad statements, there are schools where this is understood. I know because at Seneca we've spent the past five years doing what he describes, and it's been a huge success. The key to making it work, though, is missed by many of my colleagues in academia, who assume that the only way to approach this is to partner with closed-source companies. I liked how Joel said that he was going to sponsor a group to work on Mercurial--one of the best version control systems there is, which also happens to be open source. What's significant about that? It comes back to the possibility of connecting students to a new peer group.
Let me give you a real and current example. I have a student in my Mozilla Open Source Development course named Ehren Metcalfe. In this course, students are asked to work on a real project/bug within the context of the Mozilla project. We don't let them choose the project out of the air; it has to be real, which is another way of saying, Mozilla needs to care about it enough that they will get involved, will become a peer for the student(s). Ehren came to me on the first day and said, "I want to work on gdb." I probably don't need to tell you that I don't hear this often from a student. But my philosophy in the course is to let students get passionate about a topic, so if you want to hack on gdb, JavaScript, python, whatever, let's do it. There are crazy people at Mozilla who do work on gdb, so I knew it was a possibility. But as I introduced Ehren to a tool developer at Mozilla, a new idea emerged: "Want to make Mozilla really fast? We have some gcc optimization work we want done. I'll help you."
So before I continue, let's summarize what we have so far: a student who wants to push himself in a certain direction but with no formal background to do it coupled with a need from a real-world software project/company who is eager to see it happen. It's important to note, before we go further, that this sort of apprenticeship can only happen in the context of open source software. No closed shop, no matter how much they believe in the cause, is going to risk letting a bumbling student look and poke at their internal code, or allocate the time of an employee to training him/her. Students drop courses, they procrastinate, and sometimes that succeed wildly. How do you like those odds? Ready to bet your company on them?
Back to gcc, Mozilla, and Ehren. How far has he gotten two months into the project? Pretty damn close. How is this possible? It comes back to the question of peers, and the potential of open source communities to mentor new contributors. I don't want to pretend that I've taught him how to pull this off. I'm not a gcc hacker. Instead, I've taught him how to be lost productively, how to manage fear and turn it into forward momentum measured in inches. And more than this, I've gotten him connected to some amazing new peers:
The next morning I tried a new approach by consulting GCC’s bugzilla. Searching for bugs marked enhancement and containing the word “attribute” I came across Bug 36892 Support attribute((deprecated(“text string”))).
"Did you notice that your student just copied source from the web for his assignment?" I did, and he's getting bonus marks for it. More than that, I've seen him overcome his fear of sounding like a fool, and asking questions: "The other night I was stuck on this function, and so I asked on irc. A gcc dev gave me some info, and later I noticed that he'd written the file I was working in!" To date Ehren has had interactions with developers at Mozilla, Google, and Red Hat, all of whom are actively developing gcc.
Who are your peers? Who are your students allowed to talk to about their code? Who are your employees allowed to help? Ehren is doing great work this term, but he's not unique. I've got a class full of students like this, and it isn't because of something I'm doing, or something they bring (we're not a "top" school, by any means). It comes back to peers. We throw our students into the midst of the best developers in the world, we let them work on meaningful work, and we let them become peers with professionals.
Open source projects like Mozilla aren't just about code you can download. They are about peers you can work alongside. Every computer science student needs this opportunity for growth. This is how you teach software.