Page 13 -

important to recognize that no review is perfect—and that’s just fine. It may not be possi-
ble 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
completely destroy a software project if they make it all the way into the code.

Many project managers try to schedule reviews, only to meet with an enormous amount
of resistance from everyone around them. Peers, project team members, and senior man-
agers all seem to resist the idea of “yet another meeting.” Oddly, the same project manag-
ers who are unable to scrape together an hour and a half to review a scope document at
the beginning of the project generally have no difficulty whatsoever scheduling lengthy,
tedious weekly status meetings with no agenda, goal, or purpose. (Of course, not all
project status meetings have to be run that way!)

The truth is that there is no such thing as wasted time in a review. On average, every hour
spent reviewing and repairing documents saves well over an hour later in the project. This
is true because it catches costly errors early on in the project, when they are cheap to fix.
But reviews have other valuable benefits as well. By bringing team members into a room
to evaluate each others’ work, reviews foster respect among the team members for every-
one’s contributions. And, most importantly, a review results in a real commitment to the
work that is produced by the team, not just a signature.
Testing—whether it is unit testing, functional testing, performance testing or regression
testing—is just as important, and just as likely to be dismissed as unaffordable or “idealis-
tic.” Yet software testing activities are just as cost-effective as reviews. The team can’t “test
in” quality at the end of a project just by tacking on some testing tasks. Testing must be
planned from the beginning and then supported throughout the entire project. To come
up with a quality product, the entire team needs to actively look for defects at every stage,

in every document, and in the software. It’s the project manager’s responsibility to make
sure that this happens.

All Software Engineers Are Created Equal
A software project requires much more than just writing code. There are all sorts of work
products that are produced along the way: documents, schedules, plans, source code, bug
reports, and builds are all created by many different team members. No single work prod-
uct is more important than any other; if any one of them has a serious error, that error
will have an impact on the end product. That means each team member responsible for
any of these work products plays an important role in the project, and all of those people
can make or break the final build that is delivered to the users.

INTRODUCTION 5