Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers

It looks obvious until you try it.
—IEEE Software

My flight was waiting on the runway when the captain made an announcement. "We've had some trouble with the plane's air conditioning system. In a plane, the air conditioner controls the oxygen levels so we need to make sure it's working before we can take off. Restarting the air conditioning unit hasn't worked, so we're going to power down the aircraft and power it back on. These modern airplanes are all computer controlled, you know, so they're not very reliable."

The pilot powered down the airplane, powered it back up—essentially, rebooted the airplane—and our flight continued without incident. Needless to say, I was especially glad to deplane at the end of that particular trip.

The best software organizations control their projects to meet defined quality targets. They accurately predict software delivery dates months or years in advance. They deliver their software projects within budget, and their productivity is constantly improving. Their staff morale is high, and their customers are highly satisfied.

In addition to these notable successes, software pumps billions of dollars into the economy every year, both directly through sales of software itself and indirectly through improved efficiency and through creation of products and services that are made possible only with software's support.

The practices needed to create good software have been well established and readily available for 10 to 20 years or more. Despite some amazing triumphs, however, the software industry is not living up to its full potential. There is a wide gulf between the average practice and the best, and many of the practices in widespread use are seriously outdated and underpowered. Performance of the average software project leaves much to be desired, as many well-known disasters will attest.

Many projects that are lower profile than these are equally troubled. Roughly 25 percent of all projects fail outright,12 and the typical project is 100 percent over budget at the point it's cancelled. Fifty percent of projects are delivered late, over budget, or with less functionality than desired.

At the company level, these cancelled projects represent tremendous lost opportunity. If projects that are ultimately cancelled could be shut down at 10 percent of their intended budgets rather than 200 percent, imagine what a company could do by redirecting those resources at projects that were not ultimately cancelled.

At the national level, cancelled projects represent prodigious economic waste. A rough calculation suggests that cancelled software projects currently impose about a $40 billion drain on the United States economy.

When projects succeed, they can still present risks to the public safety or welfare. A project lead at Lotus received a call from a surgeon who was using a spreadsheet to analyze patient data during open-heart surgery. Newsweek magazine printed pictures of soldiers using Microsoft Excel on laptop computers to plan operations, and the Excel technical support team has received calls from the battlefield during active military operations.

Software development can be predictable, controllable, economical, and manageable. Software isn't usually developed that way, but it can be developed that way. This book is about the emerging profession of software engineering—and professional software practices that support economical creation of high-quality software.

The essays in this book address questions like these:

The parts in this book progress from looking at the trade of computer programming as it exists today to exploring the profession of software engineering as it might exist in the future.

Part 1, The Software Tar Pit, explains how the software field got to be the way it is. There are many valid reasons why the software field came to its current state. Understanding those reasons should be used to accelerate, not delay, the changes needed to make successful projects an everyday habit.

Part 2, Individual Professionalism, looks at the steps individuals can take on their own to achieve higher levels of software professionalism.

Software projects are so complex that numerous key factors cannot be addressed effectively at the individual level. Part 3, Organizational Professionalism, digs into the organizational practices needed to support more professional software projects.

Part 4, Industry Professionalism, examines steps that must be taken by the software industry at large to support professionalism at the individual and organizational levels.

Professional Software Development is an updated and significantly expanded edition of my 1999 book, After the Gold Rush. Since 1999, I've learned several lessons that are reflected in this new edition:

If you develop software for a living, this book will explore what you need to do to become a truly professional software developer.

If you manage software projects, this book will summarize the differences between poorly run and well run software projects and overview what you can do to make your projects more successful.

If you manage a software organization, this book will outline the benefits available from systematic approaches to software development and sketch what you need to do to realize those benefits.

If you are a student who wants to work in the software field, this book will introduce you to the body of knowledge that makes up the field of software engineering and show you what a career in software engineering will look like.

Industry researchers have long observed 10 to 1 differences in productivity between different organizations competing in the same industries. More recently, researchers have observed differences as high as 600 to 1. The most effective organizations are doing very well indeed.

The benefits of creating a true profession of software engineering are compelling. Traditional thinking would have it that change presents the greatest risk. In software's case, the greatest risk lies with not changing—staying mired in unhealthy, extravagant development practices instead of switching to practices that were proven to be more effective many years ago.

How to change? That is the central topic of the rest of this book.

"Sobre este título" puede pertenecer a otra edición de este libro.