Foreword

Since 1989, I've been consulting and doing architecture and programming work for various companies such as Microsoft, Intel, HP, and DreamWorks. Each of these companies has its own ways of managing the project, which includes how projects are planned, how code is written, how code is checked in (if it is at all), how the application is built, and how it is tested. It is clear to me that none of these companies has spent nearly enough time really thinking about and formalizing the process of building software. In fact, I'd say that this disorganization around the software process is the main reason why software never seems to ship on schedule and often ships years later than originally planned.

Although it is important that software companies adopt good software-building processes, it's not easy to find information on the subject. As far as software processes go, there really hasn't been much time or effort spent on this topic in articles, books, or conferences. Each company has to go about it its own way and make its own mistakes before it can learn from them. It seems that just recently, this area is starting to get the attention it needs. We can see this in Microsoft's soon-to-be-shipping Visual Studio Team System product line, which now offers deeply integrated tools for source code control, issue tracking, and testing.

In 2004, I was teaching a C#/CLR class at Microsoft when Vince approached me at the end of the class. He told me that he had worked at Microsoft in the Windows NT build lab for years and had this idea for a book about how software should be built and what kind of standards the programmers and testers should be held to. Having just recently finished a contract job at Microsoft where the build process was less than ideal, I immediately thought that Vince's book was sorely needed and should definitely be published. Also, I knew that Vince had unique experience as a Windows NT build master that made him the perfect person to write a book like this.

While reading this book, I learned many things and had many stimulating conversations with Vince about software processes that pertain to building software in an organized manner. If you are involved with the planning, programming, building, testing, shipping, or supporting of software, you will find useful information in this book. I'm sure that companies will be able to produce better products in a more timely fashion if they take the information that is in this book to heart.

After all, there is a little build master in all of us.

Jeffrey Richter (http://Wintellect.com)