Illustrates how programmers, developers, and software engineers can make their work a profession; not just a job!
° Renowned software expert Steve McConnell presents his latest thoughts on the condition of the software engineering profession
° Helps software developers regain the sight of the big-picture reasons why their jobs matter
° A thinking man's guide to the current state of software
Once again, Steve McConnell helps software practitioners become software professionals. Significant developments are afoot that will impact the careers of practicing programmers, including initiatives in education, professional development, certification, and licensing. Some of these developments are well thought out and positive; others are being forced and need to be improved before they are standardized. Software development is changing, whether programmers recognize it or not. Programmers who are not paying attention could easily find themselves working as twenty-first century software janitors. This book describes the occupation of computer programming as it exists today, and the profession of software engineering as it can exist in the future.
Download the Sample Chapter related to this title.
I. THE SOFTWARE TARPIT.1. Wrestling with Dinosaurs.
II. INDIVIDUAL PROFESSIONALISM.7. Orphans Preferred.
III. ORGANIZATIONAL PROFESSIONALISM.12. Software Gold Rushes.
IV. INDUSTRY PROFESSIONALISM.17. Engineering a Profession.
"It looks obvious until you try it."
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, rebooting the airplane—and our flight continued without incident. Needless to say, I was especially glad to deplane at the end of that particular trip.
Software development can be predictable, controllable, economical, and manageable. It can produce highly usable software that meets defined quality targets. Software isn't usually developed that way, but it can be developed that way.
The fact that some modern software systems accomplish miracles makes it easy to overlook the 25 percent of projects that fail outright and the 50 percent that are delivered late, over budget, or with less functionality than desired. The typical business system overruns its planned budget by about 100 percent, and only about a quarter of all projects are delivered within 25 percent of their original targets. Despite some amazing triumphs, the software industry is not living up to its full potential. Many of the practices in widespread use are seriously outdated and underpowered.
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.
This book explores the steps needed to move toward better practices at the individual, organizational, and industry levels. 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.
The practices needed to create good software have been well established and readily available for 10-20 years or more, but there is a wide gulf between the average practice and the best.
The view from the top looks good, but the view from the average project leaves much to be desired, as many well-known software disasters will attest. Problems with the baggage handling system caused a delay of more than a year in opening Denver International Airport. Estimates of the delay's cost ranged as high as $1.1 million per day. The FAA's Advanced Automation System overran its planned budget by about $3 billion. The IRS bumbled an $8 billion software modernization program that cost U.S. taxpayers $50 billion per year in lost revenue. After spending $44 million, a long series of overruns forced California to cancel its motor vehicle registration system. The B-2 bomber wouldn't fly on its maiden flight because of a software problem. The Ariane 5 rocket blew up on its maiden launch because of a software error. In Seattle, computer controlled ferries caused more than a dozen dock crashes, resulting in damage worth more than $7 million. The State of Washington recommended spending more than $3 million to change the ferries back to manual controls.
Even software applications that aren't considered to be mission-critical are being used in important applications. The project lead of Lotus Symphony received a call from a surgeon who was using Symphony to analyze patient data during open heart surgery. Newsweek magazine printed pictures of the Nicaraguan Contras using Microsoft Excel on portable PCs to plan operations. The Excel technical support team received calls from the battlefield during Operation Desert Storm.
Industry surveys commonly report that roughly 25% of all software projects are cancelled before delivery, and the typical project is 100% over budget at the point it's cancelled. At the company level, these cancelled projects represent tremendous lost business opportunity. If these projects could be cancelled at 10% of their intended budgets rather than 200%, 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 U.S. economy.
This book is about the emerging profession of software engineering and how professional software practices support more economical creation of higher quality software. Significant developments are underway that will affect the careers of practicing programmers, including initiatives in education, professional standards, professional certification, and licensing. Some of these developments are well thought out and positive; others are under development and need further work before they're widely propagated. This book describes the trade of computer programming as it exists today and the profession of software engineering as it can exist in the future.
If you develop software for a living, this book explores what you need to do to become a truly professional software developer.
If you manage software projects, this book pinpoints the differences between poorly run and well run software projects.
If you manage a software organization, this book outlines the benefits available from systematic approaches to software development and sketches 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.
This book is organized as a set of essays. They can be read individually or together, and they are all related to the theme of creating a profession of software engineering. They address the following questions:
Some of the issues involved in establishing a profession are legal or cultural, and they vary among countries. To keep the narrative straightforward, I have deliberately maintained a North American focus.
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 the book.
Download the Index
file related to this title.