Peer Reviews in Software: A Little Help From Your Friends
Asking other people to point out errors in your work is a learnednot instinctivebehavior. We all take pride in the work we do. We don't like to admit we make mistakes, we don't realize how many we make (or we would correct them ourselves), and we don't like to ask someone else to find them. If you're going to hold successful peer reviews, you have to overcome this natural resistance to outside critique of your work.
Peer reviews are as much a social interaction as a technical practice. Instilling a review program into an organization requires an understanding of that organization's culture and the values its members hold. Managers need to believe that the time spent on reviews is a sound business investment so they will make time available for the team to hold reviews. You need to understand why certain people resist submitting their work to scrutiny by their colleagues and address that resistance. You also must educate the team and its managers about the peer review process, appropriate behavior during reviews, and the benefits that getting a little help from their friends can provide both to individuals and to the organization.
Scratch Each Other's Backs
Busy practitioners are sometimes reluctant to spend time examining a colleague's work. You might be leery of a coworker who asks you to review his code. Does he lack confidence? Does he want you to do his thinking for him?
"Anyone who needs his code reviewed shouldn't be getting paid as a software developer," scoff some review resisters.
In a healthy software engineering culture, team members engage their peers to improve the quality of their work and increase their productivity. They understand that the time they spend looking at a colleague's work product is repaid when other team members examine their own deliverables. The best software engineers I have known actively sought out reviewers. Indeed, the input from many reviewers over their careers was part of what made these developers the best.
Gerald Weinberg introduced the concept of "egoless programming" in 1971 in The Psychology of Computer Programming, which was reissued in 1998 (Weinberg 1998). Egoless programming addresses the fact that people tie much of their perception of self-worth to their work. You can interpret a fault someone finds in an item you created as a shortcoming in yourself as a software developerand perhaps even as a human being. To guard your ego, you don't want to know about all the errors you've made. Your ego might be so protective that you deny the possibility that you made errors and attempt to rationalize possible bugs into features.
Such staunch ego-protection presents a barrier to effective peer review, leads to an attitude of private ownership of an individual's contributions to a team project, and can result in a poor-quality product. Egoless programming enables an author to step back and let others point out places where improvement is needed in a product he created. Practitioners of egoless programming also understand that their products should be easy for others to understand. In contrast, some programmers enjoy writing obscure, clever code that only they can understand, with the notion that this makes them somehow superior to others who struggle to comprehend it. A manager who values egoless programming will encourage a culture of collaborative teamwork, shared rewards for success, and the open exchange of knowledge among team members.
Note that the term is "egoless programming," not "egoless programmer." People are entitled to protect their egos. Developers need a robust enough ego to trust and defend their work, but not so much ego that they reject suggestions for better solutions. Software professionals take pride in the things they create. However, they also recognize that people make mistakes and can benefit from outside perspectives. The egoless reviewer has compassion and sensitivity for his colleagues, if for no reason other than that their roles will be reversed one day.