been bugging the department for a week? Great! Component by component, and keeping it up to a maximum of 700-800 lines of code at a time (comments inclusive) is what produces the absolute most efficient review process. Keep the code you need reviewed short, concise and independent and do the review as soon as possible after finishing while the ideas are still fresh in your mind. Just remember -- time is expensive, so don't take too much of it either! An hour should be more than enough to perform this "section review". Collect metrics. This is easier if you're using a more structured type of code review like tool assisted or formal, but can be done in OTS as well. Try to note the number and types of bugs and slip-ups you find through a given number of lines of code and units of time. Aggregate this data across developers and easily find out who needs the most help, who breaches the most standards and how much money you actually saved your company by doing code review. Soon you'll be able to actually quantify the usefulness of code review, and only then does everyone in the company become actively intrigued by it. This is usually the most difficult part of a review to implement, as few developers have the patience for manual statistics, but it can be beneficial if adopted. Be mindful of the social aspect -- finding bugs is good, not bad! It is imperative to remember that finding