We talk a lot about how to do code reviews here in the Bear Cave… which makes sense, since we make a code review tool. But an even more fundamental question is, why do code reviews at all?
I can already hear your answer: "To find bugs, Dummy!"
And you're right -- the most obvious reason software developers review code is to discover defects when it's cheapest to fix them -- before the software moves through its lifecycle to QA or to customers. Studies show bugs found in development are 8-12X less expensive to find and fix than those found in QA, and 30-100X less expensive to find and fix before they reach customers!*. And a NASA study found that code review detected almost twice as many defects per hour as testing.
But code review provides additional benefits beyond finding bugs sooner and saving money fixing them:
1. Provides real-time feedback on code while it's still fresh in developers' minds, rather than six months later when a customer finds a bug.
2. Teaches both reviewers and authors new tricks. Reviewers can learn when they see new techniques and good habits in code, and authors learn from the feedback they receive.
3. Finds and fixes maintainability issues, whether they lurk in documentation, organization, architecture, usability, efficiency, robustness, maintainability, or portability. All of these things affect overall code quality.
4. Trains developers to spot errors they might miss, and makes them much more cautious about their own changes.
5. Provides a vehicle to educate junior team members and mentor others on the team, so they can be productive without fear of causing lasting damage.
6. Improves your "bus factor." Code review exposes engineers to parts of the code base they might never see otherwise, breaking down the "my code/your code" silos and giving the team much broader exposure to the entire code base. The whole team becomes more competent on all of the code, raising the team's "bus factor." What's a bus factor, you ask? It's the number of people who would have to get hit by a bus -- or otherwise become unavailable -- before your knowledge base about your code is crippled.
7. Saves developers the angst that naturally follows when customer find bugs, not to mention preserving company reputation and avoiding the cost and hassle of fixing the problem.
8. Meets regulations for industries that require code inspection (FDA, PCI, CMMI, etc.).
9. Unites teams over the concept of a better overall product, and gives them reasons to talk to each other and improve working relationships. Team members enjoy learning and teaching, and everyone gets the feeling that the whole development organization is accelerating.
So now that modern techniques and tools like Code Collaborator make code review efficient and relatively painless, the question becomes, "Why wouldn't you review code?"
* For detailed info on these studies, get our free book, Best Kept Secrets of Peer Code Review, by Jason Cohen.
More great supporting evidence for code reviews:
- Inspection of a 20,000 line
program at IBM saved more than 85% of programmer effort by detecting
major defects through code review instead of testing.
-- IEEE Trans. on Software Engineering,
SE-12(7):744-751, July 1986.
- Shell Research saved an average of
30 hours of maintenance work for every hour invested in inspections.
-- Software Practice and Experience,
22(2):173-182, Feb. 1992.