Totally agree that more code reviews are needed. I guess then the question becomes, how do you teach someone to do a good code review. Code reviews come from experience I get it, so if you are a junior programmer then you get your code reviewed by someone senior. But there is also one very important part to a code review. It being able to give good advice to someone. Not to be over critical but to provide help that is actually going to build someone up. At a company I use to work at, they did this beautifully.

1) Every check in required a code review by a peer. In your commit statement, you specify who reviewed your code.

2) If a senior programmer wrote code for a feature that wasn't too complex he would get a code review from a junior programmer. The junior programmer doing the code review, learned what good code looks likes and second learned how to give feedback in a constructive manner as he was talking to someone with more experience than him/her.

No, traditional code reviewing is just spot checking. That is analogous to having an editor only look at a few passages of a novel. An editor needs to work with the whole text. This is the trouble with formal code reviews. Pair programming attempts to solve this by making all code get reviewed as it gets written. Like it or hate it, that at least tries to solve the core problem.

Code review might serve the same purpose (depending on how you do it) but I've had a hard time getting organizations to "buy in" to code reviews for various reasons (fear, pride, cost, etc.).

On the other hand having the Architect act as editor after the code is written not only provides the "code review" function, but it provides the additional benefit of providing the Architect with feedback on the original design, and how the abstract design ideas are translated during the construction phase.

I think it would improve communication on both sides (Architect and programmer) as well as overall quality...very nice...