This semester, we saw some outstanding work for both projects. Lots of great students, lots of good code, lots of leaps forward.
I’m looking forward to helping out next semester with UCOSP.
I won’t be doing it as a paid teaching assistant though. Why? Well…
I’ve finished school
My research paper was signed off by my two readers, and I just wrote my last final exam a few nights ago. Unofficial grades have been posted, and I’ve passed what I needed to pass.
So that’s that – I’m a Master of Computer Sciences, I guess. Awesome!
I got a job!
I’ve been hired by Mozilla Messaging to work on the Thunderbird project! I’m 100% psyched about this opportunity, and look forward to peeling into the code. An added bonus: since Thunderbird is an open-source project, I’m absolutely free to discuss the code and the various things I’m doing with it. No NDAs for me! So stay tuned – I’ll have lots to say about Thunderbird and the Mozilla Framework code. Just give me some time to wade through it.
Zihuatanejo
It’s been a pretty long road. I’ve been in school, in one form or another, for over two decades. It’s strange that it’s over. I’m extremely excited about my next adventures, but I think I’m going to miss school.
Still, I can’t help but be a bit dramatic…
[simage=735,288,y,center]
In 1966, Andy Dufresne escaped from Shawshank prison. All they found of him was a muddy set of prison clothes, a bar of soap, and an old rock hammer, damn near worn down to the nub. I remember thinking it would take a man six hundred years to tunnel through the wall with it. Old Andy did it in less than twenty. Oh, Andy loved geology. I imagine it appealed to his meticulous nature. An ice age here, million years of mountain building there. Geology is the study of pressure and time. That’s all it takes really, pressure, and time. …Andy crawled to freedom through five hundred yards of shit smelling foulness I can’t even imagine, or maybe I just don’t want to. Five hundred yards… that’s the length of five football fields, just shy of half a mile…
Andy Dufresne – who crawled through a river of shit and came out clean on the other side.
I know, I know. I left you all hanging at the edge of your seat with my last blog post, and I still haven’t posted my idea for recognizing good code review.
I’m bogged down with school work, and I’m aiming to have the first draft of my research paper done next week. So that’s taking 100% of my resources.
While the benefits of code review are proven, documented, numerous and awesome, it doesn’t change the fact that most people, in general, don’t like doing it.
I guess code review just isn’t really all that fun.
So a few months ago, I broadcast the idea of turning code review into a game. It was my way of trying to mix things up – “let’s add points, and have reviewers/developers competing to be the best participant in the code review process”.
Well, if there’s one thing that my supervisor Greg has taught me, it’s how I shouldn’t rush headlong into something before all of the facts are in. So before I decide to do something like game-ifize code review, I should take a look at some prior work in the area…
In particular, check out the following slide-show. Flip through it if you have the time. If you don’t have the time, scroll down, where I get to the salient point with respect to game-ificating code review.
Sebastian seems to be saying that adding points to apps and trying to incite competition does not make something a game. If it did, then this should be countless hours of fun.
Without play, there is no game. Points do not equal a game. It’s not nearly that simple.
Free Pizza and Pop
I’m going to divert for a second here.
Last week, a company set themselves up a couple of booths in the lobby of the Bahen Center where I work. They were there to recruit university students to work for their company – either as interns, or full-timers.
They were also handing out free pizza and pop.
Needless to say, I wanted a few slices – but I figured it would be polite if I engaged them in conversation before waltzing off with some of the free food and drink they’d brought.
So I sparked up a conversation with one of the recruiters, and he told me about the company. I’m going to call this recruiter Vlad.
I ended up gently steering the conversation towards code review, and I asked my inevitable question:
“So, do you guys do code review?”
I felt like a dentist asking a patient if he’s been flossing. Vlad waffled a bit, but the general impression was:
“Not as much as we should. We don’t have a prescribed workflow. It’d be hard to persuade all of the teams to do it.”
And then we started talking about code review in general. It turns out that Vlad had worked in a few companies where they’d done code review, and he always felt a little short changed. He said something along the lines of:
“I never felt compelled to do reviews. They just sort of happened…and I did it, and it felt like…unrecognized effort. I mean, what’s the incentive? Do you know what I mean? There’s incentive for the software, but I’m talking incentive for me. And some people did really lousy reviews…but my reviews were treated the same as theirs. I didn’t get recognized, and didn’t get rewarded if I did a good review. So it was hard for me to do them. I want to be recognized for my good reviews, for my good contributions.”
I wish I’d had a tape-recorder running so I could have gotten Vlad’s exact words. But that’s what I remember him saying.
Feedback and Recognition
Maybe instead of trying to game-ulize code review, I can instead hear what Vlad is saying and work off of that.
With the code review that Vlad participated in, all of the feedback went to the code author, and none went to the reviewers. And the reviewers are the ones who are doing all of the heavy lifting! As a reviewer, Vlad also wants feedback, and recognition for code review done well.
There’s a company in Toronto that specializes in feedback like this. They’re one of the major players in the Toronto start-up scene, and have built a pretty sweet suite of tools to facilitate quick and easy feedback/recognition.
The company is called Rypple. And maybe that’s the name of the application, too. (checks website) Yeah, it’s both.
So Rypple has this feature called Kudos that let’s people publicly acknowledge the good work of their team.
Normally, I don’t pimp companies. And it upsets me when people comment on my blog, and their sub-text is to try to sell their product or service. However, I think this video is relevant, so I’m posting their demo video so you can see how Kudos work:
So Rypple’s idea is to have a feed that the team subscribes to, and publicly display things like Kudos. The badges for the Kudos are also limited in how many you can give per week, so they’re a valuable commodity that can’t just be handed out all over the place. Cool idea.
So there’s one approach – use a service like Rypple to give your reviewers better feedback and recognition.
Or maybe we could build an extension for Review Board that does something similar, and more oriented around code review.
It’s not oriented like a game, like I had originally envisioned. But somehow, I think this idea has more meaning and traction than just “adding points”.
More on this idea in a few days. But please, comment if you have any thoughts or ideas to add.
So I wrote my (hopefully) last mid-term ever last night, and in celebration, I thought I’d put together a little video showing off the issue tracking feature I’m hoping to put into Review Board.
It’s still in it’s very early stages. The code hasn’t been reviewed. I’m still really really open to suggestions and feedback on this. So please, comment here, or on the reviewboard-dev list.
So I’ve been given the go-ahead to start writing my thesis. I was going to post up some more exciting numbers/findings from my experiment, but that’ll have to wait – the thesis beckons.
I’ve started writing it, and holy smokes, it’s hard. It’s hard because I have to zoom out from my current perspective, and start right from scratch, explaining where every single decision came from.
And I have to do it in a formal, academic tone – without awesome photos.
Plan of Attack
I think I’m going to go with Alecia on this one, and start with my outline. That’s what I always did for any of my Drama classes where I had to write a big essay: start with the outline, and treat it like the skeleton…then slowly put more flesh on the skeleton. Keep fleshing it out, throw on some skin, some clothes, a lick of varnish, and bam: it’s all done.
Anyhow, that’s my plan of attack. So I need an outline. Let me show you what I have.
Tentative Outline
Intro
Title Page
Abstract
Acknowledgments
Table of Contents
List of Tables (where applicable)
List of Plates (where applicable)
List of Figures
List of Appendices (where applicable)
The Meat
Background
Code Review
What it is, how it is commonly used in industry
Proven to be effective (Jason Cohen study)
Helps to spread learning in a development team
If code review is so good at spreading learning, why isn’t it part of the pedagogy in the undergrad curriculum?
How do we teach it?
The curriculum is already packed – how do we fit it in?
Joorden’s and Pare’s peerScholar approach
The idea:
Have students evaluate one another after assignments, and give them a code review grade based on agreement with the TA grades.
Unanswered questions:
Would students actually benefit from this idea?
What is the relationship between the marks given by TAs, and the marks given by student evaluators?
How would students feel about grading one another?
The experiment
Terminology
Assignment specification
Submission
Subject
Grader
Peer Grader
Marking
Marking Rubric
Peer Average
Agreement
Design
Single-blind, with two groups (control and treatment)
In both groups, subjects would:
fill out brief questionnaire
work on two programming assignments
have a maximum of half an hour to complete each assignment
perform another activity during the time between assignments, dependent on their particular group:
treatment group would perform some grading
control group would work on a vocabulary exercise
Subjects in the treatment group would then fill out a post-experiment questionnaire to get their feedback on their marking experience
Counter-balancing?
Graders would mark shuffled submissions
Graders would choose their preferred submission
Instruments
Pre-experiment Questionnaire
Assignment Specifications
Flights and Passengers
Decks and Cards
Assignment Rubrics
Mock-ups
Vocabulary Exercise
Post-experiment Questionnaire
Working Environment
IDE
Count-down widget
Screen capture
Subjects
Undergraduates with 4+ months of Python programming experience
Months as a unit of experience
The two graders
Assignment Sessions
Greeting, informed consent, withdrawal rights
Pre-experiment questionnaire
First Assignment Rules
30 minutes maximum – finish early, let me know
full access to Internet
work may or may not be seen by other participants in the study
may ask for clarification
First Assignment begins
Timer widget starts
Screen capture begins
Subject left alone
Marking / vocabulary phase
Treatment group
Would be given 5 submissions (secretly mock-ups), given 5 rubrics, asked to fill out as much as possible
30 minute time limit
Control group
Given links to 5 vocabulary exercises found online
Asked to complete as much as possible, and to self-report results on a sheet of paper
30 minute time limit
Second Assignment Rules
Same as first, but repeated for emphasis
Second Assignment begins
Timer widget starts
Screen capture begins
Subject left alone
Control group subjects released
Treatment group subjects fill out post-experiment questionnaire
Grading
Initial meeting, and then hand-off of submissions / rubrics
Hands-off approach
Choosing Phase
Submissions for each assignment were paired by the subject that wrote them
Mock-ups not included
Graders were asked to choose which one they preferred, and give a rating of the difference
Analysis
Pearson’s Correlation Co-efficient as a measure of agreement
Fisher’s z-score
Results
On grader vs. grader agreement
On grader vs. peer average agreement
On treatment vs. control
Difference in average
Grader preference
On student opinion wrt peer grading
Discussion
Threats to validity
The 30 minute time limit
A rigid rubric
Future work
Conclusion
That’s the current structure of it. I’m meeting my supervisor tomorrow and getting feedback, so this might change. Stay tuned.