During the last 15 years I worked for a few different organisations of different sizes.
Some of them had more or less formal code reviews as part of their software development process. In my current job for example we have a very rigid code review process that says that every bit of code should get reviewed. But why?
I guess code reviews are considered as a way to improve code quality. It's believed to have a learning effect for less experienced developers as they have to review other's code and their code is reviewed and they should get valuable feedback on their code.
That's all nice in theory but my experience is different.
In a real world project it's unlikely that you have enough understanding of other parts of the code to do really useful code reviews. (I know collective code ownership is something that we should try to aspire for but again - I have still to see that.)
So most code reviews end up with advises like: add some JavaDoc there, don't forget to cleanup imports and format the code (Yes. I know what save actions are for. Thank you!)
All of this stuff (and much more) can be done easily by PMD, FindBugs and CheckStyle. Done properly by an continuous integration server it's automatic and easy. Additionally it's much easier to accept feedback like this from an automatic system than it's to accept from the JavaDoc Nazi next door.
The saved time can be invested into stuff that really improves the code. You could start to do pair programming for at least the important modules. That's really something that creates collective code ownership and makes it possible to have more than one person that really know what's going on inside these core parts. Additionally less experienced developer can learn from the other's and the experienced developers learn how the other's think and code.
But I'm still trying to get this into the heads of my coworkers and managers.