I feel that code reviews that happen when coding is finished are too late. It is difficult to tell a person after he or she wrote a decent chunk of code (maybe thousands of lines) that the code is not good and has to be rewritten. Will you have guts to reject the code? What if deadline is looming? Will you recommend to management to cut the feature then? Are you sure you will be understood?

I believe that design review should precede coding. If you are employing TDD, design review should happen before you write your first test. Design review ensures that appropriate architecture, alrgorithms and tools are selected. It should include review of the coding schedule and review of the initial set of tests. Typically many people participate in design review, not just author of the code and the reviewer. This significantly decreases chances of discovery of a major hole late in the cycle. You may guess that design review is particularly important if feature is to be implemted by a relatively junior developer.

If you chose correct design, you may not have to perform final code review at all or perform just a quick sanity check. After all, you know that design is correct and you understand it well (you did participate in the design review, did you?) so you only have to review if the code actually implements the design and check for stupid mistakes. Good example from my team is solution for the infamous problem in the VS HTML editor. It took approximately 8 (eight) developer-months to design and implement the solution that you see in Whidbey. However, only 3 monts were spent in coding, most of the time was spent in design reviews. Interesting that the final code is not large at all. In fact, it is shorter than the previous version.

XP programming supposedly eliminates formal code reviews. However, it does not necessarily guarantee good design. After all, the design will be only as good as the best developer in the pair.