[dmharrison]

I've been in your position with a team that's quadrupled (including international staff). In the team's I've worked in it tends to work on trust, committed alot of code and senior then it's probably not going to be reviewed. Still earning your stripes then a more detailed design and an over the shoulder before commit and/or a formal review post module completion.

I tend to think you have to trust your team so I've tended even for junior guys to operate in permissive mode (I've yet to revoke someone's commit privileges). Small teams have a great advantage in that they can communicate more efficiently and often deliver quicker. If your team is growing and you can't trust (or grow to trust) what devs are committing then you're going to have longer term problems. Code reviews to me are more about mentoring and growing new staff, not enforcing 'good' code. The first question is always how could you have done this better. Why did you do it this way? Smart teams self correct so getting people to think about these things themselves tend to mean they don't repeat mistakes.

What really works is automating your success conditions, especially dumb stuff like formatting and dumb bug checking. Use continuous integration, in our dev team check in will get it running through all the tests including a full ui regression every night so if it makes it through that then it's already reasonably good. Cruise control integrated with .net and java checkstyle findbugs etc, turning warnings on as errors in the build means simple dumb stuff just doesn't happen. If someone consistently breaks the build or is checking in broken stuff then a switch to review first works. Breaking a build in our teams sends an email to the 'list of shame' (all the devs on the team) so people tend to avoid breaking it. We also don't allow any build to be broken for more than 24 hours (usually < 1 during business hours). It's all about tradeoffs and if it's a good tightly knitted team then code reviews tend to become less important.

In a distributed dev team, working remotely or getting close to release then I've found review board really good. http://www.review-board.org/ I found people commit to the continuous integration system, if it breaks they fix it and upload a diff or patch to review board. People get emailed and can mange their time more effectively, they pick the best time for reviews themselves. A 'ship it' from any of our senior team means it's done and hosed.