I live on 15 acres outside of Des Moines Iowa along with my wife, daughter, two dogs, three or so cats, and seven horses - insert your favorite "old McDonald" joke here. I mention that seemingly irrelevant fact because it causes me to use phrases that someone in midtown Manhattan may not be as familiar with, such as "That's like closing the barn door after the horses are out of the barn". The saying refers to activities that would have been a good idea about 15 minutes earlier than when they happen, whether it be equine related or in reference to the various reviews required by many software development organizations.
Reviews usually occur because people not directly involved with the project posses helpful information and choose to convey that information after it would have been most useful. Consider architecture reviews intended to verify a project's use of standards. The act of verifying standards assumes that the standards are known to the project team as they make their design decisions and that they had the opportunity to implement those standards. Standards are generally intended as guidelines that are appropriate in most situations, but may be varied from when appropriate. In order for project teams to decide whether to follow standards, they not only need to know the standards, but also understand why the standards exist. This is rarely the case, either because they fail to ask, or because the people who set the standard hoard the knowledge as to why they exist. Either way, the project team is apt to make decisions which seem to meet the needs of the project but are contrary to standards. Depending on how much emphasis a review board puts on standards, an unsuccessful review could result in additional costs to live to standards whose application seems arbitrary and capricious.
Reviews also can be used to check for complete work, as evidenced by the question “Did you think about...” While this exercise is very helpful when done in an informal “did you think about” mentoring throughout the entire process of the project, waiting to ask those questions at the review leads the project team to feel as if they were going through some sort of Spanish Inquisition, which of course no one expects. Repeated trips to the comfy chair being poked by the soft cushions will drive the project team to rely on the reviewers to catch their mistakes instead of trying not to commit them in the first place. The project teams fail to consider all the angles when they are working on something because they know someone else will do it and end up not improving their own skill sets.
The answer is to share with the project teams the real purpose behind the reviews, and to train them to check for standards complex and complete work themselves. When the project team understands what reviewers are looking for when the reviews are done, they can build those decisions into their project instead of trying to inspect in that quality after the fact. This is analogous to not keeping your horses in the barn. I close the barn door every night after the horses get out, and that is perfectly fine. We chose to get around the horse leaving the barn problem by keeping our horses in the pasture and only bringing them into the barn when we want to feed them. We in fact want to close the barn door not so much to keep them in, but to keep them out once they are done eating. Did I extend that metaphor a bit too far?