'''Architect Reviews Everything''' This was implemented at one place I worked, but it may just be a method of enforcing ArchitectControlsProduct. In our FormalReviewProcess, at least one of the system architects was involved with reviewing everything that changed in the system. This worked very well - the Architects caught several things in the developer's designs and coding that were contrary to the architectural vision of the product. I'm not sure how this pattern would fit into a code review pattern language (see CodeReviewPatterns). ---- This idea worries me. On the one hand, I have no problem with extensive code review. On the other hand this kind of practice -- funneling everything through a single authority for final review -- strikes me as a bit too authoritarian. I feel that it could lead to the "subordinate" developers not having a strong commitment to ensuring the quality of their own work; this is at odds with CollectiveCodeOwnership, which I see as a good thing. ArchitectReviewsEverything also smacks of CowboyCoding. ---- I hear your concerns. I currently employ this practice and can tell you there is a tough balancing act required. It's almost a necessity when you are a team of contractors managed by a client. When the app breaks, my client doesn't want to hear "We Collectively own the code". That might cut it on an Apache project, but she wants one person (the architect) to take responsibility (blame and fix it). If I'm taking that responsibility, I'm gosh-darnit gonna look at just about everything committed. Biggest reason: when I don't get a say in who I work with, I can't control the shite that some people write. Face it, some people just don't care about how they code. For the sake of my client's application, this Architect Reviews Everything! That being said, there's a way do this kind of a review (which I call an 'inspection') in a way that says, "I care about you as a person and want to help you become a better coder" and a way to do it that says "you're an idiot". As much as possible, I strive for the former. ---- It's what you better do when "your" butt is on the line. Those that have not been in this situation would not understand the issues of "why" it would be done this way. I can see it from both sides, because have been on both sides. It really should not be a matter of "control" when the bottom line is "quality". One should be reminded that if your name is attached in anyway to a project, should always be concerned with a quality outcome.