- We Fail Too Much
- Definitions of Success
- The Standish Group
- Doing the Wrong Things
- Doing the Things Wrong
- Time Goes By, Things Improve
- One Reason: The Civil Engineering Analogy
- Giving Up Hope
- Ignoring Your Mother
- Bridges Are Hard, Software Is Soft
- We Swim in an Ocean of Change
- Accept Change
- Embrace Change
- Capitalize on Change
- A Better Analogy: Evolving Systems
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Standish Group
In 1994, a think tank known as The Standish Group1 set out to answer this question. For more than 10 years, it studied a whopping 35,000 development projects and evaluated them in a number of ways. Its definition of success was nearly identical to the five-point checklist I outlined earlier.
The report Standish produced is long and detailed, but the overall, bottom-line numbers were shocking and, well, believable to anyone who has ever been involved in making software.
Projects that "hit all the marks" were called successful, of course. Those that were utter disasters, those that used up time, resources, and energy but were ultimately cancelled without producing anything were called failed. And, of course, there are many, many projects that end up with something, but are late, too expensive, very buggy, and so on; these were called challenged. Only 16% of the projects were classified as successful! The majority of projects, 64%, were classified as challenged, and 20% were considered failed.
Troubling.
First of all, as a teacher, I can tell you that very few developers, even today, know about these numbers. On the other hand, people who pay the bills for software development know them very well.
They know them and they sometimes think they can explain them. The interpretation I hear most often from project stakeholders when they quote these numbers is that software development is not conducted in a predictable way and that the processes that control it are too chaotic. Some even go so far as to say that software is not really developed in a professional manner, that software developers do not really focus on delivering business value; they just want to be involved with the cool tools and work around neat-o computers. I have even heard some business people express the opinion that developers actually like to deliver buggy code so that they can be paid to fix the bugs. Either way, the image that a lot of nontechnical business people have about software developers is basically that of the closeted nerd: unsocial, arrogant, and unconcerned with the needs of "normal" people.
The failure rate suggested by The Standish Group study would seem to fit this view.
I travel and teach all over the country and overseas as well. I have met more software developers in the last six months than you will likely meet in your whole life. The clear impression I get from meeting so many developers in so many parts of the world is that the notion that we, as a group, do not care about doing valuable work is dead wrong.
I admit that I used to know a few guys like that, back in the 70s and early 80s. There were developers who would overestimate their projects on purpose, and spend most of the time playing games or posting on bulletin boards. The image of the software developer as basically the comic book guy from The Simpsons was a part of the mythology of the time.
But those guys—if they ever did exist—are pretty much gone. Sadly, the image continues to live on. So, if you feel from time to time as though you are not trusted by the people who pay you to make their software, there might be some truth to that.
Besides the waste involved, there is another reason these numbers are so disturbing. I suspect that those projects called challenged and failed earlier, which in the Standish study amounted to 84% of all projects, are quite often those "death march" experiences that burn out developers.
We cannot afford the high turnover that has become commonplace in the software development industry, but it is unrealistic to think that your average adult developer will stay long in the business after he or she has gone through two, three, four, or five projects that required late nights, weekends, hostile and panicked managers, and an exhausting lifestyle that is hard to maintain.
Also, universities are seeing notable declines in enrollment in their computer science and computer engineering programs. It seems that the next generation does not view our business as all that attractive, and part of that might be the impression that the death march is the normal way software is made.
So, one way that this book could potentially be valuable to you would be if I could suggest a way to improve on these numbers. If we were more successful, this would have at least three positive effects.
- Software would be developed in a more effective/efficient manner.
- The people who control the purse strings of development would trust us more, would treat us more like professionals, and would tend to be less controlling.
- We would be able to sustain long-term development careers more reliably.
I am going to try to do that, but first we have to examine another troubling piece of data from that same study.