Peer Review vs. Code Review

I used to internally cringe when people mentioned code review – where developers check each other’s work after it has been implemented and suggest improvements. The tests were in place, QA had signed off, the product owner was happy. Surely by definition code review was just the practice of looking for problems.

If that sums up how you feel about code review, then sorry — you’re going to hate this. Nowadays, I think peer review is one of the most powerful devices for projecting best practice in a product, a team, a company and beyond. Notice I call it peer review rather than code review. To me, there are some important differences. Code review is good – it raises standards and awareness of standards. But peer review is more powerful still.

Code Review Requires Code. Peer Review Starts Before That.

Peer review should begin before a single line of code is written.

Traditionally, code review occurs after the coding is complete — when all the mistakes have been made and the time has been lost. A final check is important but leaving all the review until last can force a team into accepting a sub-par solution in the interests of time. Even when there is time to change tack it can feel like developing the solution twice.

Before coding begins a developer should discuss their approach with another developer (this is in addition to consulting with non-technical members of the team). Getting feedback early on can save a lot of headache later. Successive check-ins are encouraged, but that final check at the end becomes more of a skim than a trawl.

You may be reading this article and thinking it’s moving closer to pair programming, but not quite getting there. It’s true that pair programming gives you a similar advantage to peer review. In fact, I think effective peer review is a gateway for pair programming. It teaches a team that collaboration and interaction are key to writing good code.  

Socialize Quality

Peer review socializes a mindset of software quality in your company. I say company, but I think the ambition of peer review can be even wider than that. Those working on your project now will eventually leave your team or company and inspire others to raise standards. If you can encourage others to adopt a mindset of software quality then that will pay off again and again – for your project, your company, and the wider community.

If you are reading this article then you have an interest in becoming better at what you do. Encouraging others to adopt a pro-quality mindset is, on the long run, the single most important thing you can do for your team.

Knowledge Sharing

If it isn’t careful then a development team will naturally create silos of knowledge. The code will be informally sectioned off into areas that people are afraid to touch. Over time this system will become self-supporting – each area will be the preserve of just one developer who, rather than re-using concepts from the rest of the application, will create code with its own distinct concepts and architecture. Learning the entire codebase becomes akin to learning many applications instead of one. As a result, maintenance costs drastically increase, satisfaction declines and collaboration becomes a thing that other people do.

Peer review provides an ideal venue for knowledge sharing across the boundaries of silos. People who aren’t familiar with one area can review the work of those who are. This may not lend itself to spotting bugs but peer review is also about having a conversation and asking questions. Do it at each other’s desks if possible. The reviewer should come away with a clear picture of how that part of the application works.

These mandated conversations at the beginning of development tasks have an effect: over time silos are broken down and we forget how to build them in the first place. The project can progress even when that one special member of the team is on holiday. Improvements in one area of the code start to spark improvements in other areas and eventually it’s just one codebase again.

Training

I don’t believe that peer review should be done "at" people. It shouldn’t be one-way: experts reviewing the work of novices. There is no issue in my mind with doing it the other way around – just different benefits. Part of the reason you have experts in your team is so that they train the less experienced. Peer review provides an opportunity for junior developers to review the work of senior developers. They can discuss and understand the decisions others have made as well as learn more about a new area of the application. In an ideal world it might even teach new team members that it’s ok to ask questions and challenge things.

Not to mention, those junior members have to maintain the code. If they don’t understand it then there’s a problem. A junior resource might not know the solution straight away but they can at least provide you with a signal that perhaps the code is too complex for others in the team to maintain. When it comes to coding, simple is good but sometimes simpler is better.

Peer review isn’t just about code. It’s about cross training, instilling an attitude and promoting investment. Your team levels up and so does your codebase. If you haven’t tried it before, then why not propose it at your next team retrospective or manager meeting?