So who shouldn't be there? For some, it's important to have a representative from the business. For others... not so much. "Active members should all be coders who have a role to play," says Hemmady. "Non-technical people who don't understand code or the development process can at best be non-vocal participants. But watch out for such people to 'bad-mouth' the process outside the team afterwards."

Another issue is the involvement of the (SQA) professionals in the code review. Some feel that SQA ought to participate, at least from the perspective of ensuring that the code is test-ready from the get-go. But Horne says, "Do not, under any circumstances, invite the testing team to a code review. Their job is to make sure that your code doesn't break anything that's already in production, and to make sure that it does what it's supposed to: Code review is about how to get the best result, not what that result will be."

Testers must work with "black boxes" in between their inputs and their result sets, Horne points out. "That's their job, and forcing them to sit through what is, to them, an unimportant discussion about something they can't change can only make enemies you don't need," he believes.

In some cases, though, the code review participants you truly want may not have time for the meeting. As senior software engineer Alexei Zheglov says, "Potential reviewers should be at above-average experience levels, but they tend to have above-average responsibilities and therefore below-average availability."