How many of you feel shivers from the mere mention of the words peer review? For me, the term conjures images of long, unproductive, uncomfortable sessions in front of a projection screen defending my work like a doctoral candidate. Who needs that?
Relax. That kind of formal model is not what I’m proposing here. In this article, I’ll attempt to make a case for routine, informal peer reviews in your development organization.
Da Vinci on the keyboard
Given that software development is often more art than science, one naturally concludes that programmers are incapable of checking their own work, just as artists can’t be trusted to objectively judge theirs. Both need a critic to tell them how well they’ve done. Artists have art critics, but who becomes the code critic?
If you’re lucky enough to have access to a QA staff, you’re likely now muttering, “It’s QA’s job to check my work.” If so, you’re correct—but you’ve fallen into a trap. QA can verify that your work meets business requirements; however, by the time QA sees what you’ve produced, the vast majority of your work is hidden plumbing, inaccessible to the QA tester. Any problems discovered with the plumbing, in spite of the fact that most of it is hidden, will likely run too deep in the product to be easily corrected at this point. Remember that the emphasis here is not just on finding errors but on finding errors early enough that they can be easily corrected. Besides, even if the plumbing were visible, would the average tester understand it well enough to render an opinion on how well it was built?
So we’ve established that QA alone can’t adequately test our work as developers because they aren’t involved early enough in the process. But who does this leave us with? Management? No, no, keep them out of this—they’ll want to attach timetables to everything. Sales? Umm, no. We’re really only left with other developers, aren’t we?
What I’m proposing is an environment where multiple informal code review sessions exist as a matter of course during development. What is an informal code review? Essentially, it’s a second programmer looking over your shoulder periodically while you work, examining your work for correctness and relevance to the overall project plan or design. If this idea makes you want to run away screaming, “Micromanagement!” you aren’t alone. However, in this case, the benefits far outweigh the drawbacks.
More cooks = better soup?
The central idea here is that open, shared programming is good, while private, proprietary programming is bad. Why is shared programming better?
- More eyes looking at code find more bugs.
- Potential design issues are found earlier in the development cycle.
- Writing with the knowledge that someone else will be looking at your work often produces code that is easier to read.
- More bugs are found during the development process than in QA, resulting in a shorter QA cycle.
- The potential to share knowledge is greater in an open environment.
Finally, consider the success of the open source software movement. More than just a collection of anticommercialism zealots, the OSS movement typically involves development by large groups of freelance programmers who routinely examine, add to, or otherwise hack each other’s source code. The quality of software produced in this fashion recently has routinely equaled or exceeded the quality of software produced using more traditional, closed source methods. I tend to look at the open source approach as one big peer review, and I believe it has contributed to the high quality we’re seeing in such packages.
I’ve given you some food for thought on the importance of informal peer reviews in your organization. In a follow-up article, I’ll introduce the concept of egoless programming—a state of mind useful for implementing such a system in your organization. I’ll also propose some good citizenship rules for promoting an open environment, where peer review can succeed.