Each practice described in a best-practice chapter has been chosen for one of the following reasons:

Some of the best practices are described in Part I of this book, and those best practices are merely summarized in this part of the book.

You might ask, "Why did you ignore Object-Structured FooBar Charts, which happen to be my favorite practice?" That's a fair question and one that I struggled with throughout the creation of this book. A candidate for best-practice status could have been excluded for any of several reasons.

Fundamental development practices. Many best-practice candidates fell into the category of fundamental development practices. One of the challenges in writing this book has been to keep it from turning into a general software-engineering handbook. In order to keep the book to a manageable size, I introduce those practices in Chapter 2, "Software Development Fundamentals" and provide references to other sources of information. A lot of information is available from other sources on the fundamental practices.

In a few cases, you might rightly consider a practice to be a fundamental one, but if it has a profound impact on development speed, I included it as a best-practice chapter anyway.

Best philosophy, but not best practice. Some best-practice candidates seemed to be more like theories or philosophies than practices. The distinction between theory, practice, and philosophy in software development is not clear, and so an approach that I call a "philosophy" you might call a "practice" and vice versa. Regardless of what it's called, if I considered it to be "best," I discussed it in the book somewhere. But if I considered it to be a philosophy, it's in the first or second part of the book. (See Table III-1 for a list of where each best philosophy is discussed.)

Best practice, maybe, but not for development speed. Some best-practice candidates might very well be best practices for their effect on quality or usability, but they could not pass the tests of improving actual development schedules, perceived schedules, or schedule volatility. Those practices were not included in this book.

Insufficient evidence for a practice's efficacy. A few promising practices were not supported by enough evidence to deem them to be best practices. If the development community has not yet had enough experience with a practice to publish a handful of experiments or experience reports about it, I didn't include it. Some of the practices that fell into this category will no doubt someday prove that they have large speed benefits, and I'll include those in a future edition of this book.

In a few instances in which published support by itself was not sufficient to justify treating a practice as a best practice, I had personal experience with the practice that convinced me that it was indeed a best practice. I included those in spite of the lack of published support from other sources.

Questionable evidence for a practice's efficacy. A few best-practice candidates seemed promising, but the only published information I could find was from vendors or other parties who had vested interests in promoting the practices, so I excluded them.

Not a best practice. A few best-practice candidates are highly regarded (even zealously regarded) in some quarters, but that does not make them best practices. In some cases, experience reports indicated that a well-regarded practice typically failed to live up to expectations. In some, a practice is a good practice, but not a best practice. And in some, the practice works fabulously when it works, but it fails too often to be considered a best practice.

In one case (RAD), the candidate practice consisted of a combination of many of the other practices described in this book. That might very well be an effective combination in some circumstances. But because this book advocates selecting rapid-development practices that meet the needs of your specific project, that specific pre-fab combination of practices was not itself considered to be a best practice.

I know that most readers will still wonder about how I categorized specific practices, Object-Structured FooBar Charts or whatever. (I would.) To satisfy that curiosity, Table III-1 summarizes the best-practice candidates and indicates where they are discussed in this book or why they were left out.

The table can also serve as a comprehensive reference to speed-oriented practices for someone planning a rapid-development project.