SmartBear recently released their annual State of Code Review, in which they look at trends in the code quality space. Some interesting insights and areas of improvement can be found by interpreting the survey results.

One of the most telling statistics from the report states that 51.9% of respondents say code review is the best way to improve code quality. This number has doubled from last year, indicating that more people are seeing a benefit to having a code review in their development process. A code review will turn up bugs, performance issues, optimizations, and alternative implementations that result in better code. Better code means more reliable software. More reliable software leads to happier users, and happy users mean more sales!

What It Means for Small Teams

Given all the benefits, it’s jarring to see that 80% of teams with less than 11 people are not doing tool-assisted review. The top two reasons given for not using a tool are cost and time constraints.

• Budget is a common constraint. Teams must invest in IDEs, Continous Integration servers, and other productivity tools before even considering code review tools. If your team is budget strapped, look into Phabricator, Gerrit, or ReviewBoard. All three are open-source code review tools that can be used freely on a local server.
• Time works against every development team. There are too many features to write, and too little time to vet them correctly. Invest in your team by providing them time management training. It’ll help your colleagues in their professional and personal lives, and will hopefully free time for code review!

There’s never been a better time to advocate for code review within your small team. The availability of quality tools for a negligable cost it at a high. All you need to get started is to convince one person on your team to try it with you. With the right tool in place, it won’t take long before the entire team wants to adopt code review.

What It Means for Tool Providers

Although there are over a dozen quality tools for code review, market adoption is low as 42% of those surveyed do not use a tool currently. Budget, time constraints, and and lack of executive buy-in are the obstacles to more widespread use of a tool-based approach.

Budget is the #1 barrier to entry. While the commercial products have a higher cost than the open-source alternatives, they both generally offer a cloud-based version that can be used for a monthly fee. While this is the easiest way to adopt a tool, the cost model of $30 to $50 per month on average makes it hard to afford for teams that don’t have a large budget to spend on a license.

Yes, there are great open-source alternatives that are freely available but they have a cost in terms of installation and maintenance of the server on which the tool must be installed and configured. Tool providers should consider endorsing or publishing their own Docker container to simplify the deployment of their software. This would allow teams to focus on delivering better software by doing tool-based review.

Executive buy-in is the third most popular reason given for not doing tool-based review. This implies that tool developers could be doing more to sell their product. Indeed, looking at the product info of any of the popular tools gives a developer of a good understanding of what can and can’t be done. But for an executive to be convinced to invest, hard numbers would come in pretty handy. Graphs showing potential ROI and case studies on code quality before and after would both go a long way to showing an exec the value of investing in a code review tool.