A post from Lisa's bad brain, guest voice inside Raven’s Brain.

I have been managing a product development team at msnbc.com for almost three years now and have always seen peer code reviews as an essential activity in the certification process of a feature—a check-point that helped me sleep better at night.  The prospect of my team tripling in size in a four month timeframe got me thinking about how to maximize the benefit of the code reviews we were conducting, so I thought it fortuitous when Raven sent me the free book offer for Jason Cohen’s Best Kept Secrets of Peer Code Review and quickly signed up (btw, if you click the link, the offer still seems to be valid). Time was not on my side of course (is it ever?), and reading the book kept falling behind other priorities—we were already doing code reviews, after all, so I could sleep at night knowing our code was not going to bring down the site.  What I started noticing, however, is that the dynamic of our peer code reviews was maturing into a team-building and socialization exercise as a natural result of this growth, so when I saw the copy of Jason’s book in the stack I have been meaning to read, I picked it up with more interest than ever. 

Cohen’s book offers a number of practical, easy to implement, techniques for conducting efficient peer code-reviews--some I had already been exposed to, and some I plan to try out—but it was the chapter on the “Social Effects of Peer Review” that I found the most insightful, considering what I was witnessing within my own team.  Cohen states that his experiences with peer code reviews have uncovered “several social issues that managers and team-leads should be aware of.  Some are positive and should be encouraged in the group; others are negative and need to be addressed in a way that is both sensitive and effective.”

Unexpected positive social aspects

The “Ego Effect,” according to Cohen, is one aspect of the peer review process that leaders must be keenly aware of, as it can have positive or negative effects--it can either foster or harm team dynamics.  Since we are all ego-driven individuals, we want to be known for our success and not our failures.  When a developer is assigned to a project, he or she naturally wants the response to be positive, “oh yeah, his stuff is pretty tight.  He’s a good developer,” and not something like “he’s pretty good but makes a lot of silly errors.  When he says he’s done, he’s not.”

Cohen goes on to argue that “Old Habits Die Easy,” so peer code reviews can be as helpful to the reviewer(s) as the coder(s).  He recounts an experience where he was reviewing a particular line of code that was correct, but written differently than he would have done it.  Knowing this method would work, he could have moved on, but instead the author asked the developer why it was written this way.  What he learned in the process was a new trick that he could easily incorporate into his code.  “Normally you think of the review process as unidirectional—the reviewer points out problems for the author, and the author might learn something in the process.  But here I was the reviewer, and yet I was the one who was learning!” Knowledge sharing between reviewer and author lead to collective insights that “were spread around correctly – far faster than any other technique we could have invented.”

Cohen promises that it gets even better and suggests an exercise that involves logging every error made in a week, including such things as spelling errors in emails was well as mistakes made in code while unit testing.  According to Cohen, you will start to recognize patterns in the “mistakes” you make, and by the second or third day, the annoyance of the exercise itself will lead you to start thinking about it consciously, anticipate the mistake, and prevent yourself from making it.   “Over time you become more productive, more efficient,” Cohen states.  “You’re working faster and smarter….by observing yourself just a little more carefully and systematically.”  This, he observes, is systematic personal growth—it begins with the recognition that one tends to make certain mistakes and our desire not to make the same mistakes again leads to self-correcting behavior. 

Handling hurt feelings, and the “Big Brother” effect

If not managed proactively, however, the social effects of peer reviews can be more damaging that helpful.  Hurt feelings and the “Big Brother” effect are two negative side-effects of the “Ego Effect” that must be properly mitigated by management in order to maximize the positive social effects and minimize the negative.  Everyone responds to and/or perceives criticism differently, thus to foster the positive social effects, managers need to focus on the identification of defects as a positive.  The “Big Brother” effect kicks in when developers feel that their defect ratio will be used against them--if someone is looking over our shoulder, we are more likely to mask defects rather than focus on the positive effects of finding one!  In order to combat these factors, Cohen argues that managers need to understand that the quantity of defects found in a code review is subject to a variety of influences that do not represent the capability of the developer producing the code, and then instill this same understanding within the team.  In order to accomplish the latter, the author suggests four key messages to convey:

1. Hard code has more defects

A peer review of complex code should surface more defects than a review of less-complex code—“if your reviewer didn’t find them, wouldn’t you worry about the quality of the review?”
2. More time yields more defects
   Studies show the amount of time spent reviewing code has a direct correlation to the number of defects identified, so quantity of defects logged is not necessarily about how “good” the code was.
3. It’s all about the code

The goal of this process is to make the code as good as possible.
4. The more defects the better

Defects are learning experiences and opportunities for personal and team growth.  To drive this point home, Cohen insists that managers must reassure the team that defects will NOT be used in performance evaluations.  I found this particular argument interesting considering the interview Raven did recently with [Curt finch, who does advocates for just the opposite.

Ok, but really.  The more defects the better?  This is hard to swallow, especially for someone who used to sleep better when we found fewer defects during a code review, that when we found more, because I was satisfied this meant the code was solid to begin with. 

Rest assured, says Cohen:  “the more defects found, the better the team is working together.  It doesn’t mean the author has a problem; it means they’re both successfully exploring all possibilities and getting rid of many mistakes.  Authors and reviewers should be proud of any stretch of code were many defects were found and corrected.” 

Ok, then, the more defects the better.  If I can rally my team around that, I should be able to maximize the positive effects of the social experience I noticed our reviews becoming due to growth.  And, knowing what to look out for, I should be able to mitigate the ego-damaging factors that could undermine the intent. And our peer code reviews might just become something much more valuable than a good night’s sleep!

Posted by Lisa Forsyth at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Software Development, Code Reviews, Software Quality, Peer Code Reviews, Web Development, Programming, IT Management