I was coaching an organization the other day where they are trying to increase code quality. They believe they can accomplish this by increasing the frequency of code reviews. Currently, their solution is to get everyone into a room on a weekly basis, with junior developers demonstrating what they did and senior developers offering constructive feedback. If you've been reading my blog for a while now, you'll know that I usually find structured lengthy meetings as a wasteful activity. I'm not saying there isn't value in them. I'm just saying their cost is too much, relative to the value.

Weekly Code Review

Because the teams are trying to increase their delivery velocity, they are being forced to review their code delivery policies and rules. The weekly code reviews are creating too much of a delay. If a developer finished his or her feature on day one, they have a whole week to wait for the code review. If any changes are recommended, they lose an entire week because they still have to make the updates and get another review. The quality may be high but the velocity is low.

Pairing

My recommendation was the teams should begin pairing.  Upon review of their defined policies, it did not say they had to have a formal weekly code review meeting.  What it did say was no code would be merged into the trunk until another set of eyes had reviewed it.  By having a "code review" developer sit with the active developer, as he or she wrote code, it could be reviewed in real time and satisfy the policy.  The one week feedback loop would be shortened to an immediate feedback loop.

The Compromise

Paired programming can be a hard sell.  Management can find it hard to understand having two perfectly capable developers working on one piece of code.  But, if you look at the cost of waiting an entire week to get feedback and also having a group of developers stop work to attend a code review meeting, you can see there is a lot of wasted time and effort.  When I asked about this, I was told that the meeting was also an opportunity for developers to learn about other areas of the system.  My counterpoint was to rotate the pairs, to also offer a learning opportunity.

Because the teams would not agree to do formal pairing, but they certainly see the value in it, they decided to have a different (floating) code reviewer every day.  He or she will make themselves available the entire day to review code as needed.  I don't completely agree with this approach but it's certainly better then a weekly code review meeting.  They will be exposed to new areas of the system and the feedback loop will be shortened.  My hope is, in time, they will realize that having that second set of eyes sitting there full time will be the most efficient appraoch.

Image Quality by Pictofigo