Code Reviews

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?