How to Lead a Code Review
Your code review depends on ensuring the right people examine the software. Sure, the software developer who wrote the code needs to attend. But who else should participate in the meeting? Don't expect a lot of agreement.
CIO — Code reviews are expensive. Time spent reviewing code by managers and peers is time spent not programming. So if you're going to do code reviews, it makes sense to do them well. That's true of the process itself (see Running an Effective Code Review) and the actual line items to which you pay attention during the review.
But the first order of business is to identify who should lead the code review, and who else ought to participate in the code's evaluation. The first answer is fairly clear, but as you'll see, developers have wide-ranging opinions about the second.
Straight-up: the person running the code review needs to be a technical authority and ideally a warm and supportive leader. Micheal Lalande, director of technology at QLogitek, says, "Peer reviews are great, but if the people doing the review are less competent than the person doing the coding, there is little to no value other than possibly training a less experienced developer."
Expertise is important, whether it comes from managerial responsibility (i.e. the project lead) or the subject matter of the code being examined. "The best code reviews were ones where the code reviewer was someone of stature, well known in that particular area of development," says Lalande. "They worked closely with the development team to ensure they understand the context within which the software had been developed, and can work with the developers to understand why particular development decisions were made."
In addition to the leader being a senior engineer, she must be given authority to do code reviews from the engineering department head (Director or VP), says Christopher Buchino, director of software engineering at GotVMail Communications. "This person should have intimate knowledge of established coding standards as well as a mastery of software development best practices."
Another thing to look for, says Tim Rosenblatt, the Agile development director at Cloudspace, is someone who has seen many different coding styles. "There are a lot of people who write code very well, but will be overly (and unnecessarily) critical of code that has a different style from their own," he points out. "It's good for the reviewer to be able to objectively explain why the advice they are giving is correct. Different projects may have different requirements, so having an objective explanation helps you decide if the advice fits in with the project requirements."
But don't underplay soft skills. Marc Carkeek, VP of development and support at UC4 Software, a provider of workload automation and IT process optimization solutions, says, "You need a strong mediator to ask questions and prompt discussion, while crafting the message so the person whose code is being reviewed isn't offended."
Theron Welch, software mentor at the Microsoft Asia Center for Hardware, says, "An independent moderator can keep the discussion from getting too personal. A good moderator is someone good at running meetings, keeping people on track and focusing on important issues."
Peer Reviews Versus Code Reviews
Some developers may disagree with the above, believing that code reviews should never have a "boss" in the room, that all such meetings should be peer reviews.
Jay S. Hemmady, a former technology chief who is now working at a stealth eCommerce portal, says coders' managers might not want to attend if the meeting is meant to be a true peer-review. It's hard to avoid the feeling that a person's performance is being measured if a manager is present, he points out. "In larger organizations, this is easy to accomplish without managers. In smaller ones, often the manager is the more experienced programmer/coder!" he adds.
Yet, advises E. William Horne, systems architect at William Warren Consulting, the boss should sit through a code review if possible. "She might spot hidden agendas, grandstanding, wishful thinking or feigned interest that you may miss because your head is inside the machine," Horne says.
Scott Butler, a senior sales engineer at Servoy USA, has seen some departments that have the same developers that write the code, doing each other's code review. "If you have a very good experienced, small team, then this is fine," he says. "However, you may have a team of developers with varying skills. Sometimes the initial reaction is to still have everyone participate in code review so that you don't hurt anyone's feelings. This is a mistake. Code review should be done by your best programmers or analysts."
So much for consensus. Because "who else ought to be in the room" generates widely varying opinions.
