Modern Code Review Practices Are More Than Finding Software Bugs

[This article was written by Mary Katherine Sullivan]

It’s crazy to think that before social media we may never have been able to connect with people the way we do now. Case and point: two weeks ago, one of my co-workers was skimming through his Twitter feed when he noticed a tweet about a case study on modern day code review. After reading through the abstract, it was quickly sent my way to see if this would be a good piece of content to share on our social network which is dedicated to all things relating to peer code review.

Besides sharing the link to this study via our social networks, I knew I wanted to talk to the authors of this academic study. Two weeks later, after connecting via Twitter,  I had the opportunity to spend an hour chatting about all things related to code review with Shane McIntosh, a PhD candidate and co-author of An Empirical Study of the Impact of Modern Code Review Practices on Software Quality.

It’s Not All About Finding Software Defects

One of the first and most important questions I asked Shane was regarding his interest in studying modern code review practices. Shane explained that academic code review practices from the 1970s and 1980s are stale and old. Meetings and checklists are not the only means of doing code review these days. The stage of tooling for code review is entirely different because modern day code review is now being adopted in globally distributed open source and proprietary projects.

Shane also pointed out that early code review processes were more about bug-hunting and finding defects. While finding defects is still an essential part of the code review process today, there is a greater emphasis on the collaboration aspect. Many expect code review to be solely about finding defects but research is showing that the overall goal of code review is changing. In fact, Shane pointed me to a 2012 study with Microsoft developers that revealed how code review was now becoming more about knowledge transfer, increased awareness, and the creation of alternative solutions to problems over only finding defects.

Change Starts With Adopting Code Review Tools

Even though technology has improved, many organizations are still using the “outdated” concepts of meetings and checklists for their code review process. I’ve personally run into this when I am talking to people at conferences about what they are currently using for peer code review. Shane suggested that in order for change to occur within an organization to adopt code review tools, there needs to be a significant amount of data to prove its value (or it needs to come from upper management).

Two of the main roadblocks to adoption of a peer code review solution in a team are cost related issues and pushback from the team. Cost is an understandable roadblock because budgets are often put in place in the beginning of the year for specific projects. Having specific data, such as academic research or numbers related to cost savings, reduction in defects and time, helps enhance the reasons why peer code review would be beneficial for the team.

Modern Peer Code Review Practices Are Expensive But Pay Off

Towards the end of our interview I asked Shane if there was anything else he’d like to share regarding his research. He simply stated that he believes everyone knows they need to be doing code review, but not everyone has adopted modern code review practices. By not adopting modern code review practices, Shane explains that they don’t realize how much they are suffering because of it.

Investing in a peer code review solution may be expensive, but you’ll see that in the long run it all pays off. The benefits begin to outweigh the costs; finding defects quicker, team collaboration, improved best practices, maintainable code, etc.

In his final words, Shane makes an extremely important point about peer code review practices; you get what you put in for code review.

To learn more about this academic paper and other code review research, please visit Shane’s personal page.