Customer Reviews

The Software Conspiracy: Why Companies Put Out Faulty Software, How They Can Hurt You and What You Can Do About It

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

 

 

This book should be read by anyone who is not particularly computer-literate and has been burned by bad consumer software.

The central message of the book is that consumer software stinks because you, the consumer, buy it anyway and don't hold vendors responsible. Software intended for the general public has been so lousy for so long that people have become accustomed to it, even to the point of making apologies for the vendors. The author gives a reasonable amount of background on several aspects of software quality (technical, legal, business), some steps to take, and mentions a few resources.

The book is more about raising the level of awareness of the issue than about helping you deal with any particular bug though. Nothing will happen until there is a major change in public opinion.

Kudos for illustrating how the semi-technical press (PC Magazine and the like) contribute to the problem.

Although the author has the big picture right there are too many details wrong in his superficial presentation of the software development process for me to recommend the book enthusiastically. Nonetheless much that is in this book will probably be a revelation to the general public and so what really matters is that the big picture is right.

The resource section could have been a lot more directly useful, and should have a web site backing it. But there are some useful pointers.

******
Updated 12/27/2009

My, how time flies. I was updating my wish list and came upon this review. How quickly the issue of buggy software faded in the face of the tech crash, 9/11, Iraq, Enron, etc.

Today I wouldn't quibble with the author's presentation of the development process. It was an accurate comment but not important, the big picture was what really mattered. The book certainly has flaws (it screamed for another editing pass to tighten it up) but these are less important than the subject. Let's give credit to Minasi for taking on an important topic.

One factual error in my review: the book did in fact have a web site, the URL was just buried in the text in the normal font with no header or any other signpost (something that final edit might have caught). I skimmed the book to make sure that my statement was correct and _still_ missed the URL. But however well-hidden it may have been, it was there, and I was wrong. I thought I had corrected the review but must have lost track of it in the rush of producing buggy software.

This book should have caused people to burn software executives in effigy, or perhaps in person. Perhaps it would have if the Oughts hadn't brought so many earth-shattering problems. I'm still amazed at the continued demonstration of the Stockholm Syndrome as people make excuses for shoddy software and take criticism of vendors as a personal affront.

I would rate it 10 stars if they would let me. Software is an important part of our lives. Therefore having quality software is also important. Unfortunately the software companies seem to think that consumers don't care about quality and reliability. This book describes their attitudes, the consequences, and what to do about it. It even describes how the companies are working on making it legal for them to knowingly shipping to the consumer bug ridden software, and giving the consumer no recourse for this practice. This must stop and the book presents solutions to this. So if you ever had a problem with software (and who hasn't) buy and read this book. It is that important.

This has been happening for years! This is the only industry that has the 'End User Agreement'... '...by your agreement in using this software, and whatever happens to you because of this software, we are not liable.' Holy damn! Imagine other industries having such an agreement? 'By using this vehicle, and if anything goes wrong, for instance the steering wheel collapses or the fuel tank ruptures during normal usage on a highway, you may not hold us liable..." Or how about the food industry requiring an EUA? Or how about such things as a television? Would you put up with a television that occassionally malfunctions? Have you folks seen all the sharewares that the coders themselves release as 'beta' but still require you to register it if you want to continue use? It is BETA! They should be paying us to test and find the bugs for them.

So why do we allow the software companies to perpetuate this?

I for one am sick of it. The EUA should be abolished. We should not have to waive our rights to use a software. Especially after we purchased it, and we cannot return it once opened. If we were allowed to return a software after we used it and found it to be buggy, then this might be somewhat more acceptable.

There has to be some serious changes in this industry. As harddrive and memory increases in size, coders are lead to believed they can bloat the software as much as they want because users wouldn't be worried about space. But the more bloated software are, the more chances there are for conflicts and bugs.

Despite what other reviewers said before me, I would like to bring a different point of view. Maybe Mr. Minasi is a sunday afternoon programmer who's doesn't live the everyday life of a "real" programmer but he brings to us something precious.

The software industry is sick and needs to be regulated. He expose clearly and honestly why we, customers, should be more concerned about software quality and our rights to use these products with a reasonable set of conditions. Making a product gives a company the right to receive money for its work but that previlege should also come with *responsabilities* towards the customers. So far, software manufacturers get away with it but YOU as an accountant, an architect, an engineer or a doctor are fully responsible for every act you perform. Why should it be different for these companies ?

The issue of the license agreements is even more pathetic where abusive clauses are added as new versions comes out. The customer has no right what so ever against crappy softwares. It's clearly explained in his book...

Finally, the whole point of this book is to provide a good understanding of the industry and also educate the public toward our rights as customers to buy and use good quality products. If we let them make the rules, we will loose big time and that's what this book brings up.

This is a very important book. I'm somewhat worried that it's not getting enough attention, and though I'm hardly a conspiracy theorist, I wouldn't be surprised if certain powerful forces were doing their best to keep people from reading it.

Minasi correctly argues that companies could (and should) produce much better software than they do. Quality goes out the window because industry dynamics favor big liars--companies that continually promise new and better features, but instead ship bug-ridden monstrosities.

As Minasi realizes, this pattern will continue unless consumers and/or legislators act to stop it. Companies will only act to improve their software if they are given sufficient motivation to do so. Such "motivation" might include lawsuits, consumer boycotts, or what have you. But for the moment, the odds are stacked very much in the industry's favor.

My only real complaint is with the title. The word "conspiracy" suggests that the book was written by some kind of flake or crank. That is definitely not the case. I hope the title doesn't give Microsoft, Sun, et. al. a good excuse to dismiss the book and its author.

The first computer I programmed was a Sinclair ZX 80; 1 kilobyte of RAM, 1 MHz processor. At that time, i tried to envision what computers would look like in the year 2000, and I believed that computers would be small, extremely fast and user friendly; that they would make our every day's life easier.

Now, almost 20 years later, all I see is that computers became more powerful in terms of Megahertz and Gigabytes, but they are unreliable, unfriendly, technical beasts. Obvisously, the concept of the personal computer doesn't scale well. (Also see Norman's "The Invisible Computer").

Software is becoming an important infrastructure of our society, and still, software defects regularly are the cause of financial damages, or even the loss of human lifes - not to mention the usual annoyances millions of users experience everyday.

Mark Minasi's book is a good introduction into Software Quality. It contains some sad but true stories about defective software, which hopefully open people's (esp. software managers') eyes.

The book's title is a bit inaccurate; I don't believe in nor have I experienced something like a "conspiracy" in the software industry (altough I can imagine that it might look like one to end users).

I found it completely ironic that the book itself was defective. I've gotten to chapter four, and the first two chapters have become unattached from the binding. Usually when I buy a hardback book, I follow instructions from a book restorer - you lay the spine on a flat surface and open the covers, then a page at a time and eventually more pages. I've found this helps the book lay properly over time and not with the slant you get when you just start reading from the front. I didn't bother doing that with this book, and now I'm wondering if it wasn't a user error!

Anyway, on to the content: I found the author made very interesting points so far, but few people buy the NASA reliability argument any more. I don't buy the Motorola argument either. Sure, reliable cell phones with poor usability and poor user interface, there obviously was a tradeoff to get that "quality". The writing style itself is good. There are a few missteps so far - like regression testing is not about improving forecasting through feedback, but simply testing changes against all past tests to ensure no new bugs have been introduced.

I think the fatal flaw in the book is that all software isn't the same. Software most consumers use is different from software that web sites use, is different from NASA, is different from medical equipment. They all vary in spec and in cost, deadline, features, and desirability.

Especially in business, if you wanted a spec, you and your offspring and probably even the company would be dead before the spec was written. In a changing environment, a better strategy is to develop in an evolving style, trying out things and fixing bugs as you go along. The users understand that often they don't know how to improve their jobs, they just want it easier and more reliable. You can only learn how to build what users need (not what they want - another flaw in the book) by building the software in iterations. Sure, this isn't shrink-wrap software, but then again, most programmers don't actually write shrink-wrap software, so he's already complaining about a minority of programmers. Programmers today are just as likely to be designing business processes, workflows and management consulting as they are simply coding.

A worthwhile read, but the book is just like the software it complains about, "good enough." If that didn't actually contradict the goals of the book, I'd give it five stars.

This book is factually inaccurate and full of the authors own paranoia. I don't understand how anyone could give this book anything more than 3* - and that would be generous.

* Save your money *

My £0.02p worth: The book starts on the issue of bugs and makes some valid points, but after a few chapters Minasi disappears up his own backside ranting and raving about licensing and the law. He also repeats (almost word for word) large sections of text throughout the book - presumably because your either too stupid to understand it first time, or because he needs to pad out a bit.

Apparently NASA produce virtually bug free software - because they use methodology and redundancy. Err, why then, have they recently managed to produce a number of unmanned (thank God) piles of space junk. What's the conversion factor for cm to inches ? Apparently Motorola's mo-phone outfit in India are a shining example of how to do it right. Has Mr Minasi ever used a p.o.s Motorola mo-phone I wonder? Try a Nokia - far more pleasant.Motorola phones aren't just bug-free, they're also feature free too. Not exactly difficult to write very little that does not-a-lot.

If you believe Mr Minasi's assesment of how to make software 'bug free' then all you need are mediocre programmers that use a methodology to design, build and test their software. Egotistic programming guru's are a sure fire way to get buggy software apparently. Of course Mr Minasi knows this to be true because he's been a programmer himself and he's spoken to lots of people 'in the know' - mainly academics.

Being that Minasi is actually a journalist I'm interested to know when he last cut a line of code that actually got shipped to a user ? What companies has he worked at that actually make and ship real product ?

Methodologies can help write good software, but you still need skilled people with experience. Even then in a big project you're still likely to suffer things like the odd memory leak - which Minasi doesn't even mention as being a cause of 'bugs'.

The out of context quotations from industry big hitters just add more waffle and padding as do the lame analogies with construction projects. Mr Minasi seems to have left his brain at home here. How - exactly - would you make V2.0 of NY's world trade centre towers when the users tell you they want 3 new floors and an express elevator ? How long did it take (from initial design to completion) to build the WTC towers ? And at what cost ? Was it completed flawlesly or did it have some bugs ?

The fact is that many software projects are run along old fashioned lines - you have a goal, you get a budget and a project plan , you get staff and off you go - hopefully starting with a sound design and architecture. Projects don't fall apart because you didn't use SSADM or because software houses want to release a product with bugs. It's usually down to poor management, project planning or poor design / architecture choices. Programmers are all too often put under immense time constraints by managers who have no idea how to code - and then wonder why the product is missing functionality and has some bugs.

Well that covers Chapter 1- 3 the rest is waffle about licence agreements and the law - and is mostly US specific.

This is a book (the bit about bugs anyway) that needs to be written by a group of real programmers, not a Sunday afternoon programmer/magazine hack. So 1* - just to balance out the (i.m.h.o) overly generous other reviews.

Great book. Really great book. I absolutely loved it. Reading this book has helped me to become a better programmer. It's just great. Really great. I love it.

This author should have stoped writing this book on page 18. At this point he had already covered everything several times. Makes me think i could write a book so long as i went over the same stuff over and over.