Jay Deakins, the founder and president of Deacom, an ERP software producer for the building component and batch process industries, says, "The software code review process should really be a check off point of a well planned development cycle, not a beginning step." Yet, he points out, the code should be of reasonably high quality before it is reviewed in a formal code review.

More important than when may be how often. And that should be regularly. Russell says, "Code reviews a month after you wrote something might as well be a post-mortem. Getting feedback while your head is still 'in the code' is significantly more valuable than reviews of code you've forgotten the gory details of."

For some developers, this means a weekly formal review. For others, it's a short daily meeting.

Daily?! Won't that take too much time? Not if you're applying , such as block diagrams before code implementation and during implementation, according to developer Chuck Brooks.

Jason Cohen, founder of (which, you should be aware, sells tools to help in the process), suggests that everyone on the development team try doing code reviews for just one week for 20 minutes per day. "Set your pessimism aside for only that week, and give it a fair shake." Cohen urges development teams to measure the time spent and how many defects you find (just during this trial period), then compute "minutes per defect we find." You'll probably find it's between 8 and 15 minutes, Cohen says. "Is there any other process at your company which can uncover and fix defects at that rate? Doesn't that mean it's a good idea?"