#Agile Code Reviews

I must admit I was never totally sold on Pair Programming from the start. But I have started to come around and I was looking forward to discussing Pair Programming versus Code Reviews with a fellow co-worker who had done a lot of Pair Programming at his former employer. In the project we are both on now, there are extensive Code Reviews. These Code Reviews can last 1-2 hours with anywhere from 3-5 developers providing feedback. We were driving back to Protegra for a meeting so I thought it was a great time to discuss the Pros of Pair Programming.

Boy was I surprised.

I asked what practice he enjoyed better? Code Reviews.

Ok, but what practice was a better use of everyone’s time? Code Reviews.

Yeah Ok, but what practice did he find provided better feedback on the actual code? Code Reviews.

This definitely gave me something to consider. Now before I go on, I should provide some additional context. The developer in this case is young, quite intelligent and a great developer, inquisitive, social, and all around a good team member. I thought he would have preferred Pair Programming to Code Reviews. Especially since we discussed how Code Reviews can sometimes get sidetracked to focus on style issues rather than design issues.  Especially since he had considerable experience with Code Reviews previously and this was not his first exposure to them.

Nope. He liked Code Reviews. Here is why:

1) He gets feedback from the entire team and from people with different perspectives, experience levels, and in different roles instead of one person. Frequently he mentioned that no one ever paired with the architect so you always missed that critical feedback.

2) He found that many times the person he got paired with was someone with similar experience and expertise. So the opportunity to learn was somewhat limited.

3) He liked the retrospective aspect of Code Reviews and the ability to look back and learn after the work is done.

4) He liked how the code reviews changed the reviewers more frequently than Pair Programming. (I know you are supposed to switch who you are paired with, but this isn’t the first time I have heard the pairings are longer lasting)

So What?

So maybe Code Reviews aren’t a practice that has limited relevance in Agile? Maybe there is a place for them in addition to Pair Programming. Maybe it also depends on the team itself and the problem/solution at hand. I am aware of the benefits of Pair Programming, but if people find that Pair Programming provides limited design improvements and Code Reviews provide great value if they happen very frequently to shorten the feedback loops…..

Do we need Pair Programming if we have very frequent Code Reviews? Did Pair Programming arise due to infrequent or non-existent Code Reviews? I don’t know…

Last thought

The only remaining thing that troubles me is how Code Reviews can be confrontational and not invite input from all teammates. But maybe we can combine frequent Code Reviews with Silent Brainstorming to gather suggestions to facilitate a dialogue before the discussion starts in a Code Review.

Hmmm… I think I want to try that… Has anyone out there have experiences to share on how they have Integrated Silent Brainstorming with Code Reviews?