Make peer review a cornerstone of your SDLC

It’s well accepted these days that the peer or code review is an important part of any development team’s Software Development Lifecycle (SDLC). The basic premise being that at a certain stage colleagues in the team look over and review code being written, typically before it is released into a more formal test phase. The core driver behind the peer review is the early detection of bugs, with the theory being that the earlier you can catch an issue, the cheaper it is to resolve and the less disruptive it is to the timeous delivery of the feature set.

Despite such a compelling argument for peer reviews it is my experience that teams still struggle to implement and maintain an effective review process. Reviews are often deprioritised or rushed when there is pressure to deliver, developers form review cliques to review each other’s code and reviewing someone else’s code is often seen as not as important as delivering your own code.

The wider benefits of code reviews

There are many different forms that the review process can take and choosing the correct one for your team will depend on lots of factors including; team size, type of software being built and development methodology being followed. Independent of the exact process though I believe there are wider benefits, not always acknowledged, that the review process can bring to a team.

- Education – A peer review is an excellent time for people to learn from each other. Seniors in the team can use the forum to educate colleagues on best practices and patterns they would like to see adopted and a peer review gives juniors a stage to ask questions, learn and show what they are capable of.

- Improve team communications – If done right the simple act of getting developers together to discuss the code they are writing will help promote an environment of openness and collaboration – key elements of a well-functioning team. Using these sessions as a vehicle for celebrating success is also a great way to grow a stronger team dynamic.

- Raise maturity in the team – For people new to the process being told you could/should have done something differently is not easy to accept at first. However, with some coaching to highlight the benefits most people quickly come onboard. In a professional environment being mature enough to have these discussions is key.

- Reduce key person dependencies – Peer reviews are a way of lowering the key person dependency on the code being written. Spreading the knowledge of what is being developed in the wider team ensures that the team is better placed to deal with people taking unforeseen leave.

- Drive improvements – What happens in the reviews should feedback into the team’s push for continual improvements. Patterns in the sorts of comments being made can drive training in the team or the adoption of a tool to run static code analysis. Looking at bugs raised later in the development lifecycle can also be used to update the review process to look out for certain issues.

- Promote team ownership – Socialising their code as part of a review process should be the beginning of a transition from code being solely owned by the author to a point where the team feels joint ownership for that code. This is quite subtle and not something that is always discussed in teams but I think is key. The review should not be about poking holes in another person’s work, rather a discussion along the lines of “Is the team willing to take responsibility for this new code?” After all, once this code is in production the norm tends to be that any member of the team will be asked to support it in future weeks.

Health check your reviews

I believe there are warning signs that, despite being a mandatory part of your SDLC, your peer review process might not be adding the value it could. Developer apathy towards them is a sure sign that the review is not the first-class citizen it should be. Are the same people doing the reviews all the time? While you will naturally find some people to be more engaged its vital that reviews are done by everyone in the team so you’re getting the best possible coverage and input to the process.

How long are people reviewing for and how big are the commits? Recently a colleague of mine mentioned flippantly “for a single line change you’ll often get 3 comments and then 0 comments on the next review which happens to be 2000 lines long”. Keeping commit sizes down is vital. Studies have shown that there is a bell curve when it comes to ‘velocity (lines of code per hour) vs time spent’ with reviews[1]. If your colleagues are taking longer than 60 mins for a review you’re likely getting a diminishing return on that investment. Review fatigue is a real thing!

Ways to power up your reviews

Acknowledging that the review process has so much more to bring to your team than simple ‘checks and balances’ is key. Where possible reduce friction for the team around the review process, invest in tooling that supports reviews, such as Atlassian’s BitBucket and consider formalising slots in people’s diaries where they are expected to be reviewing and not working on their own code. Empower senior developers in the team to leverage reviews as a way of educating and promoting best practice and ask them to train your team on actually how to review effectively. Consider the metrics you can put in place to measure the effectiveness of the review process and share that information across the team so the process can evolve. Perhaps most importantly engage in dialog with your team to make sure everyone buys into and contributes to the reviews.

Sources:

[1] https://rhodecode.com/blog/69/code-review-how-to-convince-a-skeptic