Agile, Coding, People, Software Development

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

Re-posted from

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why


No comments yet.

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: