Doing spot-on code reviews with remote teams

It’s hard enough to run an effective code review when everyone is in the same room. But when developers work at home, contribute to open-source projects, or telecommute from outsourced suppliers, the challenges are intensified. Making a code review work in those circumstances requires a bit of extra effort. Technology can help, but it’s not the only way to create a collaborative team that gets the job done.

Christopher Buchino, director of software engineering at GotVMail Communications, has engineering teams in two offices, thousands of miles apart. Yet, he says, the code review process has continued to flourish. “This is more due to the importance we place on the process rather than tools, but tools have certainly helped,” Buchino says.

Desktop sharing tools are the first tools that developers and their managers reach for. “We make extensive use of GotoMeeting to allow for people participating in the review to view each other’s screens,” explains Buchino.

“Software helps a lot,” admits Paddy Sreenivasan, the co-founder and vice president of engineering for Zmanda, an open-source backup and recovery software provider whose developers are geographically dispersed across time zones. “We use an issue tracking tool as well as chat rooms to do code review.”

Atlassian’s Crucible is among the recommended tools for distributed teams. “It allows code reviews to be done offline,” says Buchino. Crucible lets him do code reviews on his own time, entering comments right in line with the code. The tool automatically sends notifications when comments are added, so developers can take action as necessary. “This also has the added benefit that all code reviews are saved along with their comments for viewing later,” he points out.

But don’t go nuts with technology. E. William Horne, systems architect at William Warren Consulting says, “Don’t ever try to use cute techno-aids like electronic whiteboards or video conferencing to solve the ‘split-team’ problem. Always provide documentation and FAQs that can be read, printed and used by any team member no matter where they are, and always take extraordinary steps to make sure that every team member has all the material several days in advance.”

As much as tools can help (and for more specific recommendations, see Making Code Review Software Tools Help, Not Hinder), non-collocated teams can’t always arrange regular meetings, because finding a mutually acceptable time is so difficult. There are two options, says Sreenivasan: Do multiple one-on-one reviews or give up on “meetings” altogether. In the latter case, code reviews can happen using alternate communications media, such as e-mail, telephone or issue tracking tools.

“Generally an e-mail is good enough, otherwise [we have] a phone conversation where both parties are looking at the code,” says James Pitts, VP of development and program management at Embarcadero Technologies. In his company, desktop sharing is rare for code reviews; it is easier for the reviewer to fix the code and send the changes back to the originator if e-mail or phone doesn’t work, Pitts says.

Cole gets full agreement from Alex Russell, the mastermind behind the open-source Ajax Dojo toolkit, who is now at Google working on the Chrome Web browser. Code reviews have to be expected, he says. “Everyone needs to know that someone else will be reading their code and have realistic expectations about what that means,” Russell says.

Is e-mail good enough? Some think so.

Meetings? Feh! Who Needs Meetings?

Some are down on the concept of in-person meetings in any case. Jason Cohen, SmartBear Software’s founder doesn’t feel that meetings are required at all. “The meeting is where the most time is wasted!” he says. ” Meetings waste time in planning/scheduling, people arriving late, distractions, people who really need to be involved for 15 minutes of it but end up staying for two hours and delaying the completion of the review because of physicality.” And that’s worse when some people are in India and some are in Boston.

If you have to have meetings, set strict time limits, strict start times and a dedicated place where all the hookups are ready, Cohen says. “Maybe make it more fun with ice cream. (Fun counts!) Alternately, use e-mail or a code review tool or even desktop sharing to do meetings from workstations where people can work on it when it’s convenient for them.”

Pitts says, “Do not do code reviews in a meeting setting unless you also write the code in a meeting setting. If you want to instill a repeatable code review practice, you need to let people review the code on their own and provide feedback to the originator.”

For some, the solution is to avoid distributed teams altogether. Marc Carkeek, VP of development and support at UC4 Software, a provider of workload automation and IT process optimization solutions, has had issues with having two development teams separated by the Atlantic Ocean. “We’ve found that tightly coupled projects, meaning ones that require high team cohesion and communication, are very challenging in these situations.” Carkeek’s new rule of thumb is, “Any project that requires more than two one-hour meetings per week shouldn’t be split between development houses.” Even loosely coupled projects need face-to-face meetings occasionally, he says, usually once per quarter, to keep communication operating smoothly.” (For more on making telecommuting work, see Getting Clueful: Seven Things the CIO Should Know About Telecommuting.)

That’s not always an option-particularly in open source development, which by its nature has people contributing code from all around the world. Manoranjan (Mano) Paul, the software assurance advisor for (ISC)2, which specializes in information security education and certification, points out that reviewing open-source code needs a little extra attention. “The control over open source developers is limited, if at all existent,” he says. “Where open source software is to be implemented within the organizational computing ecosystem, special attention needs to be given to the code portions that will be used. In such cases, a manual code review should not only be conducted statically (where lines/blocks of code is reviewed) but also dynamically (where APIs, protocols and formats are tested using random inputs to determine the behavior of the software code). Fuzzing or fuzz testing is an example of dynamic code review.”

That’s not just about arranging for appropriate meeting times, he says, or technology substitutions for in-person meetings. It also applies to the code review itself. “At a bare minimum, checks for security should be performed,” he says (belying his personal focus). “Code review must be performed with special attention to maintenance hooks, backdoors, impersonation constructs, Easter eggs, canonicalization issues and logic bombs (difficult to detect in code review automatically and so manual review is necessary) to ensure code quality and security.”

While these situations are somewhat exceptional, most of the process in conducting effective code reviews applies equally-or perhaps more so, with all the difficulties of distance communication.