Section 1.5. Doing the Project Right Is Most Efficient

1.5. 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 whistles" 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 contains advanced applications of these tools and techniques . The goal of this book is to help a project manager put the basic versions of these practices in place quickly, in order to see immediate improvement in the efficiency of a project.

Software engineers are a very practical bunch. They do not like adopting practices unless they believe they will see a net gain from them. A practice must save more time than it costs to implement. Every single tool, technique, and practice in this book is time-tested. These practices (or similar ones) have been used in many successful projects around the world and in organizations of all sizes. These practices would not have found such widespread adoption if they were not efficient.

All of the effort that goes into reviews, unit testing, requirements engineeringeverything that does not directly produce codepositively affects the bottom line of your project. If it looks like a lot of work, you should think about the effort you are saving by not having to fix the problems later when they show up as defects in your software. What's more, you can be confident that we optimized the techniques that you are putting in place in order to make them as easy to adopt as possible. But most importantly, you can be sure that your project will go more smoothly with them in place than it would without them.

This principle is most important when a project starts to slip and a deadline looms nearer (or when one is blown altogether). It may be tempting to start cutting out these practices and concentrate all of the effort into pumping out code. That's one of the most common mistakes that project managers make. Cutting out good project management practices will make the project take longer, not make it go faster.