I think this piece from Hacknot, "In praise of Code Reviews" hits upon some of good reasons people don't do code reviews. It do think there are a few more though.
Tool support. It would be really, really nice if you could check something into a holding area for review before it was actually committed. I know some source control systems can handle that, but it's usually non trivial to set up, or hard to use. I'm not in favor of the "SCM as a workflow tool," but I've always thought that a place to stash things for review that was easily integrated would come in handy. Not an excuse, but if tool support were better they would be more common I think.
More importantly though, very few people can do them properly. Every mandatory code review system I've ever seen produces a bunch of people talking about formatting, or naming conventions, etc. Stuff that could practically be taken care of by a tool is written up for fixes. "Missing standard copyright header." "Not throwing standard exception type here."
I've seen some of the worst, buggiest code I've ever seen fly through code reviews with a "looks good." In fact, of all the large codebases I've seen, the worst have all passed mandatory code reviews. Why? Because it's hard to criticize someone else's code. People take things personally. And in the interests of not causing divisions in teams where people maybe don't get along so well already, even those who know better have a tendency to keep quiet.
The only fix I can suggest if you want to start reviews is to start with your own code, and get someone on the team who you have a good relationship to start really digging and finding defects. Set the tone yourself, and hopefully a culture of constructive criticism will work its way into your team.
If you already have that culture ingrained, then I'm guessing you're already writing less buggy code than teams that are afraid to call out bad code when they see it. If you don't have that culture, team dynamic, or type of people amenable to it, you need to develop it. Otherwise no code review is going to help very much.
On the reviewer side, one of my problems with code reviews is that for anything non-trivial, I often don't have anything really constructive to say other than, "hm... that feels wrong", unless I've actually had the time to try to write the same feature myself.
Also, sometimes on the surface, it sounds sort of reasonable as someone explains it, it's not until I actually try extending it that I discover it sucks. (This is assuming the problems are less obvious than what the hell is public void getXXX supposed to do?)
Trying to come up with an alternative design to some code that I barely understand the first time I see it is way beyond my abilities so I assume also beyond the abilities of most of those reviewers whose suggetions were mostly formatting related.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: