8 of 9 people found the following review helpful:
3.0 out of 5 stars
This could have - and should have - been better, September 21, 2003
This review is from: Software Development Failures (Hardcover)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
4.0 out of 5 stars
finds common factors to many failures, October 17, 2005
This review is from: Software Development Failures (Hardcover)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
2 of 4 people found the following review helpful:
1.0 out of 5 stars
A failure in itself, September 30, 2003
This review is from: Software Development Failures (Hardcover)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No