Review Everything, Test Everything
Reviews get a bad rap. Many people see them as frivolous. "In a perfect world," many project managers say, "we would review all of our documents. But we live in the real world, and we just don't have time." Others feel that the only reason for a review is to force various people to sign off on a document—as if a signature on a page somehow guarantees that they agree with everything that it's stapled to.
The purpose of a review is not to make a perfect document or to generate a page of signatures. Rather, a review does two things: it prevents defects in the software and it helps the project manager gain a real, informed commitment from the team. What's more, it's important to recognize that no review is perfect—and that's just fine. It may not be possible to catch 100% of the defects before coding has started, but a good review will catch enough defects to more than pay for the time it took to hold the review.
It is always faster and cheaper to hold a review meeting than it is to skip it, simply because it's much easier to fix something on paper than it is to build it first and fix it later. When a review turns up an error that takes a few minutes to fix in a document, it saves the team the hours, days, or weeks that it would take to fix the error once it has been built into the software. But even more importantly, reviews frequently uncover errors in documents whose resolution requires a lot of discussion and decision-making. Errors like this can ...