Customer Reviews

Software Development Failures

5 star:		(0)
4 star:		(3)
3 star:		(1)
2 star:		(0)
1 star:		(1)

 

 

Software development failures, depending on how you count, may outnumber the successes. Nearly a third of software projects are simply scrapped before completion. That waste may account for as much as US$85 billion, approaching 1% of the US gross domestic product. This topic is critical, in a world where everything, down to the pacemaker in a patient's chest, is driven by software.

A topic so important deserves a more stirring author than Ewusi-Mensah. I found this book dry, repetitive, and poorly organized. The book centers on a handful of case studies. Those case studies are barely mentioned until chapter four, though. Even then, I found it hard to follow the examples. The author does not present the samples one at a time, in their entirety, though. Instead, he presents one aspect of all five examples, then another facet of all five, and so on. Only in chapter seven, when the book is winding down, do I really see any depth in any of the case studies. Even then, just one is covered in any detail.

Ewusi-Mensah rightly describes the "code of silence" surrounding software project failure. His description the phenomenom seems shallow, though. Bruised egos and painful memories may well be part of the reason that failures get so little mention. Software training and practice may have more to do with the tendency to ignore failure, though. In every other field of engineering, practioners rely on knowing yield strengths and "absolute maximum" ratings of their parts and materials. The idea of failure is central to the practice, even to the legalities and forensics, of those fields. Programmers, though, are barely ever shown good examples of their craft, let alone bad examples. Management, design, and project control of software are even more ethereal - there simply is no common set of terms in which the failure can be described.

Petroski's writings show that engineering failures can be described in informative, constructive ways. Perhaps this book's target is more difficult - it discusses not the failures of the software itself, so much as failures in the process by which software is built. Perhaps, too, not every author can be a Petroski. Maybe the academic treatment really is more appropriate to this topic. If so, I would hope for an author who cites more of the field's literature and cites less of his own prior work.

It's an unfortunate empirical observation that many large software projects fail. Why this happens, and how it can be avoided is the subject of the text. The author looks at several abandoned projects, for which solid information has been made publicly known. These include the Denver airport's baggage handling, and the IRS Tax System Modernisation. Though surely many other failures have been quietly buried by other groups.

The author finds that often, constraints, schedules or goals were placed outside the influence of the developers. While this does not pre-ordain failure, it seems to significantly increase its possibility. Another characteristic trait seems to be a lack of executive oversight. Leading to project drift, until that becomes irreversible.

The book's best help to you might be when you are starting a project.

unfortunately this book does not deliver what it promisses. neither i find any theoretical in-depth analysis of specific software project failures nor reasonable checklists to guide practioners. instead, many common places that do not add value compared to the publications on the topic so far (Boehm, Jones, etc.).
it does not help that the book fails to describe the problems that make specifically software projects so hard to manage. see the freely available NATO software engineering conference papers from 1968 for more helpful information on software project failures.

Here's a two-ingredient recipe for disaster: take a big organization and mix in ambitious plans for a state-of-the-art software system. The disaster already happened at the IRS and Denver International Airport, both victims of software development missteps. Such failures are common, costly and all-too-avoidable, writes academic Kweku Ewusi-Mensah. While his prose can be dry, the examples he uses prove quite juicy. A little common sense could have saved the IRS billions and the Denver airport millions. Both fell victim to surprisingly basic pitfalls, such as unclear or unrealistic goals and over optimistic expectations that inexperienced people could get the job done. Ewusi-Mensah convincingly argues that organizations need to share such learning experiences, although he acknowledges that would mark a reversal from common practice. We recommend this book to managers and engineers involved in developing software. This cautionary tale could save your neck.

Here's a two-ingredient recipe for disaster: take a big organization and mix in ambitious plans for a state-of-the-art software system. The disaster already happened at the IRS and Denver International Airport, both victims of software development missteps. Such failures are common, costly and all-too-avoidable, writes academic Kweku Ewusi-Mensah. While his prose can be dry, the examples he uses prove quite juicy. A little common sense could have saved the IRS billions and the Denver airport millions. Both fell victim to surprisingly basic pitfalls, such as unclear or unrealistic goals and over optimistic expectations that inexperienced people could get the job done. Ewusi-Mensah convincingly argues that organizations need to share such learning experiences, although he acknowledges that would mark a reversal from common practice. We recommend this book to managers and engineers involved in developing software. This cautionary tale could save your neck.