The Software Conspiracy

Jason Bennett has returned with a review of Mark Minasi's The Software Conspiracy. The book is basically a well-informed perspective of the state of the software industry - how it functions, what it does, and what's really going on. Click below to learn more.

The Software Conspiracy
author	Mark Minasi
pages	271
publisher	McGraw-Hill, 09/1999
rating	8/10
reviewer	Jason Bennett
ISBN	0071348069
summary	A non-technical (but well-informed) telling of the state of the software industry

Background

A short digression before I start my review of this quite interesting book. I had the privilege of spending a few days in Seattle at a Construx Software training event on OOA/OOD using UML (hi, ImageX!). Amazingly enough, seven hours of flying each way will give one plenty of reading time, even including talking with those herding into the seats around you. Although I almost missed seeing my hometown Titans in the Super Bowl, I feel it was time well spent. Alas, I didn't get to see Steve, but maybe he'll email me if he reads this. :-)

Nevertheless, on to the business at hand. My book reviews have generally centered around the concept of software engineering, and how to apply its principles to development efforts. This week's book is more of a review of the state of the industry, and where the industry is trying to go. It should come as no surprise to most people reading this that the picture is not particularly pretty. There is, however, a glimmer of hope, but only if we can shake off the combined forces of greed and apathy. Hey, I never said it was going to be easy! <g>

What's the book about?

I believe the book's subtitle just about sums it up: "Why software companies put out faulty products, how they can hurt you, and what you can do about it." As I said in the summary, this book is geared toward non-technical software users in an attempt to explain to them why their software breaks, and why they shouldn't take it anymore. Many parts of this book will be well-known to regular Slashdot readers, but I dare say there are parts that will raise your hackles, regardless.

Chapter 1 is more or less an overview of the theme of the book: that software bugs are bad, that consumers and the media tolerate those bugs to an unreasonable extent, and that those same consumers must act to stem the trend toward more broken software. I'll address his on-point evidence as I discuss the following chapters.

Chapter 2 addresses an important, if not always obvious question: why do software bugs exist in the first place? The short answer is that it's difficult to think of every possible interaction and exception when devising an algorithm. The author employs some interesting mental experiments in the process of the discussion to make this fact more evident to non-programmers. He also mentions some historically important bugs (including the recently-historical Y2K). So far, nothing earth shattering....

With Chapter 3, the journey moves from easy to confrontational. To sum the chapter's theme in one sentence, software is buggy because programmers are slack and customers are more slack. As a counterpoint to the oft-heard statement, "Bug-free software is impossible," Minasi examines the Capability Maturity Model in detail, including how it has been shown to reduce error rates, and why most firms do not employ it. You won't feel complimented by this explanation. In short, most software firms don't try very hard to keep defects out of their software because they expect defects to occur, and (according to one survey), 15% of software firms do not even bother to test their software at all before shipping. I'm always one to quote the adage about the three kinds of lies, but somehow I'm inclined to believe this one. Why don't firms test? Basically because they can get away with it, and programmers don't want to be told they've made a mistake. The argument that bug-free software is too expensive is, of course, the same argument the meat packing industry made at the end of the 19th century, that wholesome meat was too expensive and impossible to produce. Fortunately for everyone, that excuse was eventually put to rest. Minasi believes the software excuse should be equally put out of its misery. The author does make one point that I disagree with, however, in that he claims that process isn't really for "geniuses," only "regular" programmers. I would argue, however, that everyone needs process to channel whatever genius they may possess, and that structure does not stand counter to creativity. The author also addresses some of the shortcomings of the CMM, but in the end believes that the evidence behind process, any process, is overwhelming.

Chapter 4 moves into another arena near and dear to our hearts: UCITA. As I read this chapter, I kept finding my jaw hanging open in astonishment at the gall of the software industry and the law they have crafted. This book is fairly recent, and thus the information current, although I recommend checking Cem Kaner's site or Slashdot for the most recent information. I won't go into bloody detail here, but suffice to say under UCITA the software industry can disclaim all responsibility for their software, while simultaneously putting unreasonable restrictions on your usage of that software. Amazingly convenient, huh? You could also no longer treat software like a book, as the software industry would completely control the software even after you had purchased/licensed it. Needless to say, a raw deal for the consumer.

Chapter 5 proposes an interesting rehash of Yourdon's The Decline and Fall of the American Programmer. Now, before I proceed, I've never actually read that book, so this analogy is based on my understanding of Yourdon's thesis. Basically, Minasi compares today's software industry to the auto industry of the 1950's. At that time, cars had more or less reached technological maturity. Marketing ruled the industry, as all the car were more or less the same. Planned obsolescence was invented, and quality declined as more and more useless features (e.g. fins) were added to cars. Of course, we all know the end of that story. The Japanese car industry invaded and smacked Detroit around for a while before the American automakers were able to recover. Minasi proposes that the America software industry is in a similar situation today, and UCITA could exacerbate that tendency. Could another country's software industry rise up? Minasi doesn't really offer any competitors at this point, but the threat is certainly there.

Chapter 6 exhorts users to stand up for quality software, just as they would stand up for quality in other products. Write letters. Don't pay for bug fixes. Help stop UCITA. Nothing earth-shattering again, but important nonetheless.

Chapter 7, the conclusion, paints two pictures of the future, one rosy, where buggy software is brought under control, and one bleak. I won't spoil them for you, but suffice to say the bleak one might surprise you. In any event, and effective storytelling mechanism.

Finally, there is an appendix of how to fix you current software, or at least get around its problems. Programmers might scoff at the information contained therein, but your mother will likely find it useful.

What's Good?

If you don't want too technical of a read, and you're interested in why software is in its current state, this is an excellent and informative book. The rationale is sound, and the information on UCITA is important to educate others about its dangers, especially when the time comes for a vote in your state. In short, read this book if you're tired of crappy software, or you don't know why software is crappy.

What's Bad?

On the other hand, if you think process is silly, and you're doing the best you can, dangit, you won't enjoy this book. I would like to think that most open source proponents would understand the importance of testing, but then again I don't remember reading too many test plans for OS projects. Whatever. Regardless, this book might not be for you if you want a detailed, technical discussion of the state of software, and you're already well up on your UCITA info. YMMV.

So What's In It For Me?

Regardless of who you are, coder or suit, what this book discusses will impact you. The U.S. software industry is going to be fundamentally shaped for decades to come by what happens in the next few months and years. It behooves you to understand the implications of where we are going, regardless of where you stand on the issue.

• Table of Contents

• Introduction
  1. When Some Bugs Bite, They Kill
  2. Why Are There Bugs? How Defects Happen
  3. It Doesn't Take a Genius, It Just Takes a Process: Building Good Software
  4. Software and the Law
  5. Bugs and the Country: Software Economics
  6. Fighting Back: How to Improve Software
  7. The Future
• Appendix: Software Self-defense
• Endnotes
• Index