Peer review--design review, code walkthrough, and so on--is an integral part of a mature software process. Despite the benefits a focused, well-executed peer review gives to the development effort, it's one of the most neglected tools in shops using immature processes.
By forgoing peer review, software developers miss opportunities to learn from the successes and failures of others.
Peer review lets the designer or the coder draw from the experience of the rest of the development team and from other stakeholders in the software project. That broader base of experience lowers the risk that a software product will fail to fulfill the capabilities and reliability required of it. It helps designers and developers improve their repertoire of patterns, techniques, and skills.
Without peer review, flaws and inefficiencies become a permanent part of the product. Moreover, developers working on different parts of the same project may end up duplicating effort because they aren't aware of what their colleagues are doing, resulting in inefficient stovepipe systems that prove difficult to maintain.
Like most any other practice, peer review can be done badly, to the point where it is ineffective and wasteful of the team's time and resources. This is especially true when personalities and egos are allowed to dominate the review. Care has to be taken to ensure that the design or the implementation is the focus of the review, and that egos are kept out of the discussion. [To be continued]
Chuck Taylor --