Navigate back to homepage - Caricature image of Ryan Tyrrell

Hi, I'm Ryan!

I build web sites & apps for entertainment brands

The Value Of Peer Review

A few years ago, with a software team I worked with, we made the decision to go all-in on peer review for a particular project. I can honestly say, it is probably the single most valuable thing I have done in my years as a software developer.

We knew we'd be bringing more developers on to the project over the course of its lifetime and that everybody would need to move fast across front-end, back-end and supporting services.

We defined peer review as:

"Other people reviewing our output during the design and development phases in order to understand what we're doing, why we're doing it and to improve upon how we're doing it. Peer reviews are not a way in which others can criticise, rather a structured approach to help with knowledge sharing, mentoring and improving quality."

It was initially a hard thing to convince the team of. Peer review wasn't something we were well versed in and it was felt it would be a huge time-sink, but I was confident we would see benefits from it very quickly, and we did. Peer review gave us great results immediately, and is now something I strongly condone for every project. Even if there is only one person contributing to a codebase, having their peers review their approaches and decisions will improve the skills and efficiency of both the developer(s), and the reviewer(s).

We have found the following benefits from having a strong peer review process:

  • Knowledge improvements all round
  • Less code duplication
  • Fewer code conflicts
  • Bugs are caught sooner
  • Development time on the project is decreased
  • Juniors are onboarded faster
  • Innovation is encouraged

Ultimately, our client was very pleased with the quality of our output and our speed of delivery, which is what matters, and this improved with each feature or sprint we completed.

For this particular project, we used Bitbucket to host our codebase using Git. The rule was that all code edited in the codebase must have a pull request created for it, which should be approved by at least two other developers before being merged in to the "release" branch. We found this approach worked well as it accounted for when one or two developers were not in the office or were deep in a feature. We used Bitbucket's pull request commenting and task systems to prompt conversations, raise concerns and suggest other approaches where required. In general, we'd review all open pull requests at least once a day, ideally twice (first thing in the morning and straight after lunch) and either approve the pull request or leave a "blocking task" against it. Only pull requests that had no open tasks, two approvals and a green tick from passing the automated tests could be merged.

I wanted to highlight a few comments and questions raised on some of the pull requests we created, to show how effective the process was. Screengrabs below with some data hidden.

Knowledge sharing

Screenshot of a pull request comment explaining how container resolution can provide future benefit to developers

Screenshot of a pull request comment detailing that unit tests are timing out when running

Catching bugs

Screenshot of a pull request comment explaining a bug that was found during testing

Screenshot of a pull request comment suggesting team best practices

Stability improvements / Long term considerations

Screenshot of a pull request comment suggesting refactoring a component for reuse elsewhere in the project

Screenshot of a pull request comment requesting that a GET http request be changed to a POST for security reasons

The common criticisms for peer review are:

Time needed

Project managers and product owners may push back and suggest that peer review can't work because of the time needed, which would affect cost to the client or deadlines. We're confident that peer review actually significantly saves time over the course of a project and beyond. Improved quality and knowledge sharing means we keep getting faster and stronger in our day-to-day roles, whilst reducing bugs in the products we build.

Feature delivery will decrease

We're confident that this can be mitigated with sensible planning. Providing developers aren't assigned lots of tasks that each require the previous one to be completed before moving on to the next, peer review will work fine and won't slow down feature delivery. Branching methodologies in Git can help with this, as can agile planning and execution of tasks.

Could introduce harmful, trollish behaviour or stress on the team

This is the only criticism I can understand, but to be honest, if you're working with people who would intentionally troll or be mean to their colleagues when reviewing their work, I think you've got bigger problems to solve. Nobody in my team is an idiot - we don't hire people who exhibit these traits and I've never worked with anybody who hasn't wanted to help me and improve their game too. If you're in a team with idiots then I'd suggest getting out of that team, it's not worth your energy trying to deal with that every day.

If you are not currently practicing a peer review process in your team, particularly if you are building software, I cannot suggest more strongly that you start doing this right away. Let me know if you'd like any help getting set up or if you have any questions!