Customer Reviews

Software Runaways: Monumental Software Disasters

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

 

 

After reading the other reviews of this book, I expected to find a light read more likened to "America's Most Shocking Police Videos", but I was mostly disappointed.

The first series of articles on the Denver airport debacle (reportedly they set out to build the largest airport in the country but ended up with second-largest airport in Denver) made virtually no reference to software. The contractors of the baggage system ran into problems with physical access to the terminal, changing requirements, and uncooperative City officials, but they didn't discuss the software issues much. It was a typical political mess.

The story behind the FAA's failed air-traffic-control system was the most interesting technically, and the failed New Jersey DMV project was enlightening about using the wrong tool for the job.

The story on the failed California DMV system is *two pages* long, and they mention "unspecified software problems" as being involved. The story about the Adidas warehousing software failure was three pages long, and I did not find a single lesson to take from it. These do not look like any inside information to me.

This book was a fairly enjoyable four-hour read (really!) but it was not worth the $30 I spent on it. Borrow it from the library or a friend before spending yours.

This book suffers some major flaws, which are not well represented on the back cover or in the introduction.

1) The story telling is incredibly dull. The author desperately needs some lessons from Cringely.

2) The story telling is all third-hand. The author had no first hand experience in any of the disasters, nor did he bother to personally interview any of the participants. Instead, he simply compiled information from public media sources.

3) The story telling barely relates to software development at all. Many of the stories superficially relate management failures or legal battles with hardly a reference to the actual software projects/issues.

4) The story telling is often not even by the author himself! Some of the stories are simply reprints of professional journal articles by other authors. Tellingly, these are often the more (barely) interesting stories.

I think the book cover misrepresents the contents substantially. I felt sort of ripped-off. 2 stars only because it is one of the few books that collects a lot of this information in one place.

This book's subtitle is "Lessons Learned from Massive Software Project Failures." A more accurate subtitle would be "Assortment of InformationWeek articles written about costly failures that involved software." This is a shallow and superficial book. There is no original research, no original reporting, and no deep analysis.

Sometimes there are three separate articles on the same failed software project! This is pointless repetition, not any type of deeper analysis. It's like reading a xeroxed collection of articles, except it's in a glossy cover. The "author" writes a few paragraphs before and after each project.

The quantification, if there is any, involves the dollars exchanged in the settlement between the two companies. No numbers about anything technical ever appear.

This is a good book if you're a consultant and you want some scary stories to tell a CIO. If you want advice, read one of Steve McConnell's books.

Although this book can hardly be called original (most is reprinted articles), the material inside is well worth the recreational reading time of a software developer or manager. Most articles are light and informative, although the reader may be pressed to find application for the 'lessons' learned therein. Only one glaring bad spot in the book: a master's thesis is included that covers the Bank of America MasterNet failure. This 'thesis' is so poorly written and difficult to read, I question the value of the writer's degree. Otherwise, the book is firmly in the 'okay' category.

The book is a previously unattempted collection of a series of papers from different sources about big and resounding software project failures. The emphasis is on management and organisational rather than on technical issues. Overall, it enlightens about what can go wrong and how, analysing the most common failure reasons.

This is a collection of project disasters with an eye towards the major project management failures rather than the technical issues. Though many of these have been previously published, the assembly is worth price of the book. This will be is valuable for anybody involved in high-level decision making on mission-critical (and smaller) IT/Internet software projects. If you want to educate your boss on why you can't begin work without clear objectives, scope, senior management involvement, etc., a few of these stories should clear his/her head. All the B-to-B internet hubs run by consortia should read this or be ready to end up in vol II.

...Most of this book consists of reprints of articles about particular runaway projects, including the Denver airport baggage handling system, the FAA's next-generation Air Traffic Control system (which replaced single keystrokes with 12 or more mouse clicks), and Bank of America's MasterNet. Some of this is interesting, but only some, and only somewhat; there is very little analysis, except in the introduction (which is worth reading).

If you're looking for a solid book on avoiding IT disasters, this isn't it.

On the other hand if you want to see what not to do, if you want to find good examples of what can go wrong in IT, if you need to put the fear of God in a CIO or a manager, then this is your book.

Collecting reports on some of the worst, stupidest IT mistakes, the book examines what went wrong and why. It's dry and depressing reading (about halfway through I had to take a break), but its also informative. These are the real deals, and they aren't pretty.

Though this will not be the greatest book you read or the most helpful, it's still very, very useful. It's good as a compliment to more helpful material, but the useful collecting of data and the attempts to be unbiased earn it 4 stars instead of 3.

All this book contains is a collection of newspaper and magazine articles about software failures. The in-depth analysis promised by the back cover blurbs consists of a very short summary section at the book's end and grouping the articles into sections based on why they failed.

No one likes failures... but that is not a reason not to like this book!
Software runaways is a very valuable book: page after page we are given inside details of major software project failures. It is not often you are given such a front seat view on disasters.
Unfortunately, it is hard learn something out of this book. The worst part is that I do not think I learned anything out it. And yet I still give it five stars! The reason is that this book should be taken as a "measuring and testing device", read it every ten years and see how much you have progressed, see how much your management style could have worked in those situations. Long ago, I read it from cover to cover; Today, I read parts of it. Now, a bit wiser, I can understand better why some of these failures happened. And that is a great feeling!