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.

Web conferencing software encourages the interactive process during a code review. "People can step through the code together and whiteboard ideas on how things could be structured differently," says J. Schwan, managing partner of Solstice Consulting, a Chicago-based technology management consulting firm.

"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.

Is e-mail good enough? Some think so.