The trick, of course, is to run code reviews soon enough and often enough to find problems, without getting in the way of writing the code in the first place.

For many teams, the code review cycle should start . Steve Porter, technical program manager at Imaginet Academy, suggests that team embrace design reviews instead of code reviews, because the latter can sometimes occur too late to correct any errors. "Design reviews help identify the various paths you can take to get to the final solution and help the developer or team make the right choice early, instead of after time has been spent writing code for review."

Christopher Buchino, director of software engineering at considers the code review to be particularly useful or when someone new joins a project. That helps developers learn the team's standards, style-wise and architecturally. "Having uniformity in the code base is extremely helpful towards maintainability, and this is a good way to get people writing code in a similar fashion," Buchino says.

Suggests QLogitek's Lalande, "Do the code review as soon as you feel comfortable with the on code that have been identified as requiring manual review."

Overall, however, experienced developers feel that code reviews ought to be a non-negotiable part of the software development lifecycle-and should not be voluntary. Alex Russell, the guru who is now at working on the , says, "Code reviews don't work when they're optional. They need to be as much a part of your routine as merging from trunk is."