Page 14 -

There are many project managers who, when faced with a disagreement between a pro-
grammer and a tester, will always trust the programmer. This same project manager might
always trust a requirements analyst or a business analyst over a programmer, if and when
they disagree. Many people have some sort of a hierarchy in their heads in which certain
engineering team members are more valuable or more skilled than others. This is a dan-
gerous idea, and it is one that has no place on an effective project team.
One key to building better software is treating each idea objectively, no matter who sug-
gests it or whether or not it’s immediately intuitive to you. That’s another reason the prac-
tices, techniques, and tools in this book cover all areas of the software project. Every one
of these practices is based on an objective evaluation of all of the important activities in
software development. Every discipline is equally important, and everyone on the team
contributes equally to the project. A software requirements specification (SRS), for exam-
ple, is no more important than the code: the code could not be created without the SRS,
and the SRS would have no purpose if it weren’t the basis of the software. It is in the best
interest of everyone on the team to make sure that both of them have as few defects as
possible, and that the authors of both work products have equal say in project decisions.
The project manager must respect all team members, and should not second-guess their
expertise. This is an important principle because it is the basis of real commitments. It’s
easy for a senior manager to simply issue an edict that everyone must build software with-
out defects and do a good job; however, this rarely works well in practice. The best way to
make sure that the software is built well is to make sure that everyone on the team feels
respected and valued, and to gain a true commitment from each person to make the soft-
ware the best it can be.

Doing the Project Right Is Most Efficient

The first part of this book is a presentation of techniques, tools, and practices for every
phase of a software project. They are designed to be implemented one at a time and in any
order (with a few restrictions). This means that you have a lot of freedom to choose the
approach that is best for your project.

But no matter which one you choose to implement first, you can be sure that your project

will be better off with the practice than it would be without it. This is because building the
software correctly the first time is always preferable to doing it wrong and having to go
back and fix it.

Every practice in this book is designed to help you build software efficiently and accurately.
What’s more, there are many ways to implement every single one of these practices. We put
a great deal of effort into developing the most efficient version of each tool, technique, or
practice we present in this book. We did this by stripping out as many of the “bells and whis-
tles” as possible from each practice without compromising its basic integrity.

There are more complex and involved ways to implement every single idea in this book.
Wherever possible, there are references that will point you to more in-depth reading that

6 CHAPTER ONE