Chances are good that you’ve never produced or seen a flawless piece of useful code—especially in the early stages of its development. In his recent article ”The case for informal peer review in a development organization,” Web Editor Lamont Adams recommended informal peer review sessions as a sensible way to ensure quality and consistency early in the development process. In a follow-up discussion, many TechRepublic members agreed that there are benefits to informal peer reviews, but they suggested that certain conditions must be present for such reviews to work effectively. Here’s what they recommended for valuable and enriching peer reviews.
Attitude is everything
Although the goal of such peer reviews is to create an informal environment for code evaluation, it helps to make sure that everyone shares the same expectations. Member D. Brinson believes that code reviews can be very rewarding, but they can also turn ugly if a participant doesn’t understand the concept of constructive criticism.
“These can be very positive experiences. However, I have also been involved with reviews where a coworker regarded them as a personal attack. This was a terrible experience that caused tension in our other dealings and was a complete waste of time.”
Even though the criticism in Brinson’s case wasn’t meant to be insulting, an embittered coworker could easily see peer review sessions as an opportune time to humiliate or offend someone. Daniel Mendelevitz, a consultant, believes that this is where some formality is due.
“You must set rules ahead of time so that no personal attacks are permitted….It is very important that this process be managed for the benefit of all.”
Forget about seniority
Part of setting the tone for an effective review session is ensuring a level playing field for all developers. Information specialist Stéphane Parent has found that senior developers often think it’s a good idea for their junior colleagues to critique each other’s work, but they don’t include themselves in the process.
TechRepublic member Dennis Dickens suggested that both junior- and senior-level developers should exchange criticism of their codes. He said that by doing so, the overall quality of the code would improve and the developers themselves would benefit from the interaction.
“Junior developers can learn things that the senior developers have known for ages. Senior developers can keep up on new concepts and technology.”
Programming is far from black and white. It’s a highly subjective field that’s difficult to objectify and standardize in many cases. And not every critique has a positive effect.
Dennis Dickens said that when he was studying architecture at California Polytechnic University, San Luis Obispo, he disliked review sessions between teachers and other students who criticized your creative efforts.
“I’m creative and often have a different approach to problem solving. [I’m] one who looks at programming as a box of LEGO blocks that you can put together in infinite combinations.”
If a review session is going to be productive, peers must realize that there are going to be different styles and approaches. According to Dickens, holding on to the convention of “the way we’ve always done it before” is shortsighted and humiliating to the developer. In short, peers need to have an open mind.
Know your critics
In some cases, a developer may feel that his or her critics are limited in their ability to review the code. For example, Joel Altman, a software engineer with Lockheed-Martin, claimed that his reviewers know little about his unique environment.
“Few of them can program assembly and those who do aren’t familiar with the hardware. They find some errors, but in reviewing their reviews, I often find more than they did.”
Altman doesn’t suggest that this is bad. After all, the mistakes were spotted and corrected as a result of the process. However, his case does illustrate the limitations that peers may have if they are working outside their domain or expertise. Community Editor Jerry Loza believes that in order for a review to be effective when reviewers have limited expertise, the reviewers’ role may best be that of interrogator.
“Hopefully, they know to ask the right questions and not try to offer programming tips.”
Do you have any advice for effective peer interaction and criticism? Are there any horror stories or tales of success resulting from a peer review? Join the discussion and share your thoughts.