Matt Welsh writes a great essay about all the wonderful aspects of code reviews.
I thoroughly agree. Code reviews are just about the best tool available to teams trying to improve their software.
Matt's essay discusses the many benefits of code reviews (yes, there are lots of benefits, for the reviewers, the reviewee, and for the overall organization), and suggests a number of useful tools and techniques for accomplishing them effectively.
What Matt doesn't discuss, unfortunately, is why it's so hard to get good code review practices established in an organization.
I've been in a lot of software development situations, with a lot of phenomenally great programmers. Sometimes there is a healthy code review culture, sometimes there isn't. And I still, after 30 years, don't understand why that is.
Invariably, executives will sing the praises of code reviews, teams will experience their benefits, but in practice it is very hard to consistently and thoroughly employ them.
Kudos to Google for making it happen, somehow; Welsh's article doesn't really say why Google has succeeded at this when so many other organizations fail.
Of course, there are many things at which Google succeeds while other organizations fail, so this result is neither surprising nor particularly illuminating in that respect.
Still, I suspect I'll wonder til the day I retire why it is that organizations will seem to grasp at so many other aspects of the software development process (team structures, agile methods, scrums and Kanban walls and burndown charts, IDEs, CI systems, project management automation, etc.) yet don't perform the basic and incredibly powerful technique of universally employing code review.
Does your organization have a code review culture? If so, how did it come about and how is it sustained?
Peer reviews of code are very effective. I started doing them 30 years ago.
ReplyDeleteThe boss has to make it part of the process: insist on it and not undermine this with things like: "skip reviews -- we don't have time." In a leaderless/consensus group, someone has to be an advocate and use persuasion and peer pressure.
Materiality is crucial too: toxic arguments over style drain energy and support. Often, the most vociferous opponents of good programming style are the worst programmers, especially when it comes to maintainability and testability. It is best to choose an existing style standard (there are hundreds of good and proven available for free) and use it, even if there are some objections. When someone insists on particular nit, make it their job to convince everyone that all should do it that way.
There's always been someone who has an allergy to reviews, and I've never found a way to change their mind. Next time, I think I'll allow the sneezers to opt-out and then hold them accountable for bugs that escape and could have been found in a review.
Tools help to reduce the friction and focus on problems that human intelligence is best at finding. I've created a list in my blog post
http://www.robertvbinder.com/blog/supporting-software-inspections-and-reviews/