In Feature Driven Development, we use code reviews as a method of quality assurance and team learning. Feature Teams form under a Chief Programmer to develop a batch of Features in a Chief Programmer Work Package. The purpose of batching is to absorb the overhead - what Paul Szego termed "administrivia" - in a Feature. This would include the domain walkthrough which requires resources to be scheduled, as well as project tracking meetings and the design and code reviews. Doing this on a Feature by Feature basis would be cumbersome and inefficient. CPWP's enable efficiency in the development tasks.

The code review is intended to be executed by the Feature Team and allows each of the team to learn from other members how their code works. It propagates the best knowledge of the entire project in terms of architecture, design patterns and coding guidelines and the result is both quality assurance (reduced defects and high internal quality) and learning. The code review process helps to raise all the developers on a team to the standard of the best.

Some who believe they are running FDD projects let code reviews degenerate into Chief Programmer code re-writes. In this form of review, the CP simply takes the code off each Feature Team member and re-writes it with them in a pair programming fashion. This may deliver the desired quality assurance in terms of reduced defects and improved internal quality. However, it will not deliver the desired learning and it will not raise the standard of the team to that of the best. Rather the effect will be to freeze learning and stem further improvement. Furthermore, the process of code re-writing is demoralizing. The long term effect will be to undermine trust and respect in the team. Developers will lose the sense of pride in their work and the result will be greater defects produced at a slower velocity. Resentment against the chief programmers may develop and the team will over time become dysfunctional.

Code re-writing may seem like a good idea. It is simpler to schedule and uses fewer resources. It may also seem efficient and psychologically pleasing to the geekier of chief programmers. But ultimately it is soul destroying. It eats at the core of a project team and destroys its ability to create value. Peer reviews may be hard to do properly but code re-writes are not the answer. If you can't get peer reviews right for whatever reason then go the whole way to the other extreme and pair program. It has the same effect - improves external and internal quality and enables learning. It also encourages developers to take pride in their work. Pair programming does not carry with it the demoralizing side effect of the code re-write by the super uber-being of the arrogant chief programmer. Chief programmers have a responsibility to lead and leadership in knowledge work means in part teaching. A chief programmer who does not teach is not a chief programmer just a team lead directing others.