Peer Reviewing – What is it and why should we do it?

Good afternoon everyone! Today I will be discussing Peer Review, a technique that I have come across in the work place and have found as an incredibly rewarding experience. If you have any questions, comments or feedback please don't hesitate to comment in the comment box below and I will try to reply as quickly as I can. Thanks! 

What is Peer Review? 

Peer review is the examination of someone else’s work. The intention is to find and highlight any possible errors within the design (or back-end code) that may not have been spotted by the other developer, whilst the aim is to improve the eventual quality of the solution produced. Reviews can be completed in various forms and commonly features during pair programming, though I have had experiences of this technique used during database design and development as well (which makes sense seeing as the database is the central hub of any web application!). Speaking from experience, I have found pair programming a rewarding experience by not only increasing my own skill set and broadening my thought processes, but also for increasing overall team morale. Occasionally, meetings are held afterwards to discuss any issues that were discovered. You may find that there were no major problems and that adaptations could be made to make the application run faster and more reliably, or to make code more readable so that other developers can understand exactly what each routine is trying to achieve.

What are the steps of Peer Review?

(Please click on image for original size).   

What are the Benefits?

There are many benefits of peer reviewing work within your business:

Code is reviewed from a different perspective.

Not everyone thinks in exactly same way. Therefore, there is a chance that one developer may see something that the other will not. They may also have separate ideas on how certain tasks may be carried out, particularly if one developer has more experience than the other. This is not a bad thing as there usually is no right or wrong answer, just one that may be more efficient than the other.

Improved team morale.

As team members will be producing more reliable solutions, team morale will be increased dramatically as the confidence of each developer grows.

Improved communication between team members. 

As team morale improves, so does the level of communication. It has been a common misconception for many years that developers are quite introvert and code on their own. However in reality, this simply is not true as they communicate with testers, other developers, project managers and sometimes clients as well to ensure the quality of the software that they are producing. Improved communications during peer review will promote comparing ideas, decision making and will increase the knowledge of both developers working together.

Fewer bugs and more reliable code.

What one person may spot in a peer review may be missed by another as everyone works differently. Therefore, working together definitely has its added benefits in this instance. Deadlines will be met more easily as there could potentially be fewer bugs that could be easier to fix with two minds on the problem instead of one.

Fewer phase iterations.

If the code-behind and database created are more reliable and fewer bugs are found, this means that fewer iterations of testing and bug fixes will need to be performed. This could eventually reduce production costs, which is fantastic for both the business and for clients as the business could have faster turnaround times, and as a direct result of this reducing the cost for the customer too.

Improved usability.

Also, as a developer, it can be easy to forget about the usability of the software you are making and although it may make sense to you (after all you are the developer who created it!) the other developer can pick up on areas that could be improved. This can commonly involve improving performance and making the user journey of the software flow better, which in turn could reduce the number of change requests from the client. Again, this will save time and money to give the best solution possible to the client. 

However...

1) The peer review method is not supposed to replace a developer testing their own work, so no slacking there! A developer must know how to unit test and review their own work as well as others as it allows them to learn from their own mistakes made and shows an element of independence, especially when other team members are not available for peer review (due to a tight deadline, for example).

2) Peer reviewing is also not supposed to replace a tester, just clear up most (if not, all) logical problems before the new adaptations reach a tester, which they would really appreciate as they can focus on testing more intricate parts of the system.