How to avoid code review bottlenecks when some of the team pair program

Question

There is a school of thought that describes code reviews as the number one priority activity for all developers in a sprint since they are either:

a) A source of unrealised value

b) A source of bugs

While I'm not sure I subscribe to such as black and white view, I do agree with the sentiment.

But enough of the background.

We have a persistent problem where reviews sit on the queue for days at a time. Invariably the bottlenecks are caused by the lead developers as they're more in demand. Also, due to the important nature of their work, they tend to pair program so they don't require their own code reviews to be done as such. Hence there is no real incentive for them to do reviews as a quid pro quo.

The most often used complaint is that they will lose their train of thought while programming. There is some truth in this, but surely they could just review after lunch or first thing in the morning?

Are there any ways round this? On previous projects we have applied a SLA of one day which worked well for the most part but again, the rule tended to be broken by the pair programmers.

Developers take it in turns to do code reviews so the load is already being shared fairly.

Answer 1

The teams should be empowered to review their own code, after all there's no one better qualified.

GIT Pull Requests implement one of the easiest and most robust models for this:

• Code cannot be merged to master until it's been reviewed by X (two is recommended) other people, usually there's a stipulation of one dev and one tester
• Anyone can code review. A junior asking questions can have the same effect as a senior critiquing. It's about picking up complexity and edge cases.

There are a few things you can do to make it easier:

• Pair programming counts as a code review (after all it was developed together)
• Keep changesets small, there are many many many reasons why this is a good idea
• Don't auto-assign to your most experienced, busiest people. Let other team members pick up code and let them take pride in the code base
• Consider creating an extra state (or including it in the Definition of Done) for your stand up boards. Like all bottlenecks, make it visible so people can see work that needs to be done to unblock people
• Consider using automated code review tools so people can focus on the important stuff, not the automatable rules

Answer 2

If you perform pair (or mob) programming, do you need peer review?

I've previously written an answer on the reasons why one would want to perform peer code reviews in the first place. However, all of these are also addressed by pair programming. In essence - pair programming is a real-time, highly interactive code review.

It may be easier to say that your code must either be pair programmed (and set up some team norms or guidelines around effective pairing techniques) or go through a code review, but both aren't required. Of course, you can always add a code review to get a third (or fourth) set of eyes on a change, but if you simply have a need to ensure that two people are watching and ensuring the quality of every change, pair programming gets you that.