#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?


Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

One thought on “#Agile Code Reviews”

  1. For me, agile is about principles rather than specific processes. So if code reviews are working for you, awesome!

    I’m not sure, though, that your dev really gave pairing a fair shake. On the high-functioning agile teams I’ve seen, not only do pairs switch often (promiscuous pairing) but team members make it point to pair themselves with as many other team members as possible. Notice I said “pair themselves” as compared to “…the person he got paired with…”. For me, part of a self-organizing team is having team members that take responsibility to make a process work if it’s a process that the team has agreed to try.

    It sounds like in your case, making things work was choosing a different process altogether, which is great too!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: