Code Review. Why and when should it be done?

Joseph,
Extreme Programming (XP) takes code reviews one step further, by teaming developers together in a practice called "pair programming."

A common managerial criticism of this practice is that it reduces productivity. But this criticism is based on a flawed assumption that writing software is nothing more than pounding keyboards. If this were true, we'd hire developers based on typing speed. In reality, though, development teams are not held back by typing speed, but by the flow of ideas. Pair programming accelerates software development by allowing programmers to solve problems together.

Although this is a defining practice of XP, there's a fundamental XP principle which states we must be willing to let go of practices that are no longer useful. From that aspect, if you find that code reviews are a waste, then you should be willing to change the way you're operating. I would suggest, however, that before your team simply abandons code review, you first ask why code reviews are not effective.

This is a matter of quality assurance. Is not a wasted at all, mainly if you are working into Agile based environments.This is not a new practice. This is an old practice. The problem is into the attitude of people that are in charge to conduct the review. Is like when you face an audit process. Most of the auditors think that they must behave as police woman/officer.

Peer review should be essential to ensure good and consistent quality of the deliverables. It enables adherence to established standard practices, proofreading of contents and most importantly, the verification of approach pursued in the deliverable.

Well, answering this question is a little bit tricky. this task may or may not be a waste. It has to do with your strategy, plan, etc.