Foreword by Capers Jones

David Longstreet has been a colleague for many years and we share common interests in software development and software metrics.

In his new book Reboot David takes a careful look at the software industry and the factors that affect the outcomes of software projects. These are some of the same issues I deal with in my own books. I’m glad to say that David and I seem to have reached similar conclusions, even though in recent years we have worked with different clients and in different countries.

Software is a troubling and paradoxical industry. On the plus or positive side, the software industry has brought forth amazing products that have changed the way people communicate, work, and even the way they entertain themselves. On the minus or negative side, large software projects have the highest failure rates of any commercial product in human history. Even when large software projects are not total failures, they usually run late and exceed their budgets by large amounts. And when the projects are delivered to customers, they are filled with thousands of bugs or errors.

David Longstreet’s new book he takes a long hard look at both the current state of the software industry itself, and of current software development practices. David concentrates on worst practices or the factors that have so often led to failure of software projects.

Among these worst practices can be found inadequate quality control, sloppiness when dealing with requirements changes, failure to select the most suitable technologies for projects with special needs, and the naïve belief that software generalists can handle complex technical tasks such as testing applications and achieving a high level of defect removal efficiency. In other technical fields, formal specialization has allowed professionals to achieve in-depth knowledge of important subsets of the overall knowledge of the profession. But software has not yet achieved enough sophistication to have many true specialties.

David’s book also examines some interesting if sobering trends in the software industry itself. For example in recent years there have been sharp declines in software engineering graduates and also computer science graduates. Some of the reasons for these declines are troubling facts for the industry. First, over the past 15 years a lot of U.S. software work has migrated to India, China, the Ukraine, and other countries. The perception among young college students is that the U.S. software industry is no longer a high-growth industry. Second, software engineering is not a true engineering profession with certified professionals, so the status is much lower than other forms of technical work. I frequently encounter developers of embedded software who refuse the title of “software engineer” even though they develop software. They prefer the titles of “telecommunications engineer” or “automotive engineer” or some other discipline whose professional status is higher.

As David points out, many industries in the past had periods of explosive growth followed by periods to steady decline. A brief look at the history of American commerce will show that industries such as railroads, automobile manufacturing, cloth and clothing manufacturing, and ship building the United States dominated world markets for 50 to 100 years, and then lost market leadership to other countries with lower cost structures or more sophisticated manufacturing methods. There are troubling signs that the U.S. software industry has peaked, and is perhaps now slipping into a period of decline.

David’s book is not just a book of the author’s opinions. He has worked with enough clients in enough industries to have gathered a substantial amount of solid quantitative data. David presents interesting observations on the quality and productivity levels of a number of industry segments such as finance, manufacturing, civilian government, and defense. Each of these has different averages and tends to go about software development and maintenance in somewhat different fashions. For example the companies that develop embedded and systems software usually have better testing and better quality control than banks or insurance companies, primarily because companies that build complex hardware know that only high quality will let it operate successfully.

The topics in David’s book are all interesting and all important. The book deals with issues that all of us who work in software need to understand.