I recently wrote a post asking the question “why aren’t code reviews part of every undergraduate computer science curriculum?”, Gregg Sporar responded by saying

I don’t know of many professors who are really “into” code review.

This is so strange.

You would think that a process that provably helps reduce code defects earlier in development would be right up there in intro programming courses, along with “use a debugger instead of sprinkling print statements everywhere”.

So, what gives?

Well, one thought is that perhaps these courses are structured so that peer code review would completely undermine the ability to evaluate students correctly. I’ve been in plenty of classes where I’ve been instructed never to show my code to anyone else. We can vaguely discuss issues on the course bulletin board, but absolutely no code can be discussed directly. For these assignments, team work, plagiarism, and cooperative learning is a big no-no.

At first glance, it’s perfectly understandable:  it seems like the only way to fairly evaluate the abilities of each individual student. But still, it seems like that particular teaching model is really missing out on a huge opportunity to give their students valuable feedback.

I have to make some corrections, though. I haven’t been completely honest. I’ve made it seem like I’ve never had any code review done in my courses at UofT, and that’s not entirely true. Quick examples: in CSC180, I did pair-programming with another student – and pair-programming is certainly a type of peer code review. In CSC301, my team would rigorously review the diffs of each other’s repository commits, looking for flaws, and emailing back and forth defect reports. We weren’t explicitly instructed to do this, but it certainly seemed like a good idea at the time for the success of the project.

But it’s nothing like this.  Look at it this assignment from Carnegie Mellon.  What a great idea for an assignment!  How come this type of assignment seems so rare?

Back when I was an Electrical and Computer Engineering undergrad, one of my professors once told me that “great programmers write great code because they read great code”.  I think this is something that was missing in my formal education: how to read, review, analyze, and critique code. And above all, what beautiful, elegant code looks like!

In my academic Drama classes,  we poured over tons of famous, landmark plays.  And of course we tore them apart, boiling them down, analyzing them, critiquing and debating, arguing our pants off…  I got good at reading them.  My critical evaluation skills in this area are pretty sharp.  I can tell when I’m reading something really well done.  And, because of this, given some practice, I could probably write something half-decent if I put my mind to it.

So I think that’s something I’m missing from my computer science education.  Perhaps there’s a good reason for it’s absence – but if there is, I don’t know it.  Instructor moderated peer code reviews, or (even better!) code reviews of industry software…that sounds juicy.  That sounds useful.  That sounds like valuable feedback and instruction.

It’s too bad it never happened.

Anyhow, I haven’t answered my question yet.  I still need to finish my review of Smart Bear’s Cisco study.  I’ve also found a case study where code peer reviews were used as part of an introductory computer programming course – I’m interested to see what they found out.