Slashdot Mirror
Why Software Sucks
Trent Lucier writes "Why Software Sucks professes to be a book for computer users, not programmers. Author David Platt wants to be the informant, pulling back the curtain on software development so mere mortals can get a glimpse inside the sausage factory. Platt flaunts his geek cred, all the while implying that he's not one of those geeks. But ultimately, trite observations and a condescending tone left me wishing that the book would end long before it did." Read the rest of Trent's review.
Why Software Sucks...And What You Can Do About It
author
David S. Platt
pages
272
publisher
Addison-Wesley Professional
rating
5/10
reviewer
Trent Lucier
ISBN
0321466756
summary
Explains to non-tech people why software quality is so bad.
The spectrum of what constitutes bad software is mostly limited to usability, security, and stability. No mention is made of supremely sucky software features like digital rights management, spyware from "reputable" companies, and bundled bloatware. There is plenty of information about these topics that the general public could benefit from, but none is to be found here. To his credit, Platt does mention annoyances like "free registration required" news sites and privacy issues.
The chapters focusing on software shortcomings all have a similar structure. The problem is put into historical context, a reason is posed about why the problem still exists, and readers are given advice on how to fix it. The insights into the world of software development are limited and stereotypical. In Platt's world, programmers are ego-driven, awkward geeks who only care about creating whiz-bang features at the expense of usability and usefulness. They're elitist and lazy, passing off responsibility to the user via confirmation dialogs and convoluted options menus. They go to tech conferences and pay more attention to the amazingly realistic software rendering of a bikini babe as opposed to talking to the real woman standing right next to them.
Of course, stereotypes are often true for a subset of any population. But Platt's characterizations are shrill and condescending, often reading like they were co-written by Comic Book Guy and Ann Coulter. Little mention is made of anyone else in the development process besides programmers. (Because, you know, in the history of the world, a marketing manager has never had a bad influence on a product. Nope, never happened).
Usability labs are cited as a great way to improve product quality. Great, but who is in charge of funding usability labs? Not programmers. Most programmers I know would love to have their product improved upon with usability testing. And by the way, if you think the previous sentence lacked supporting evidence, get used to it, because that's the level of research that is found (or not found) throughout Why Software Sucks.
The examples are typically shopworn (Yes, the Google homepage is simple and easy to use. We get it. Lord Jesus, we get it.) or trivial. UPS.com is constantly scorned throughout the book because it asks the user for their home country instead of detecting it via the user's IP address. Starbucks.com commits the deadly sin of defaulting to a 5-mile radius for it's store locater instead of just listing closest stores. Yes, these are annoying faults, but are they really the best cases out there?
Readers are given advice on how to improve software quality, and it all boils down to boycotting bad products, sending letters to companies, and spreading the word among friends. If you need more firepower, you're out of luck. How can I get my employer to use better software products? Or my local government? Can I leverage accessibility and usability laws in the fight against bad websites? Are those crickets I hear?
In the second half of the book, Platt takes a turn towards sociology and tries to explain the environments that geeks gravitate to. His prime example is the Microsoft Tech Ed conference, which, given the way he describes it, doesn't sound very different from any other kind of conference. Marketing bozos, gratuitous tschotchkes, after-hours drinking by the speakers...it could just as easily be the annual gathering of the Coffin Retailers of America.
Platt has mastered the art of the non sequitur. Theorizing that maybe the problem with software is that the field is too male dominated, we are told that, "Many people think that the recent child molestation and cover-up scandals in the Catholic church stem at least in part from the hierarchy's all-male culture." Gotta love those "many people" and what they think might "in part" be a cause of a problem. "Like Israel, Microsoft is finding out that being on top isn't quite as much fun as it looked like it would be when it was on the bottom." Does that make Apple the PLO? My favorite example is when Platt draws inspiration from How To Win Friends and Influence People. "Dale Carnegie lists rules #7 for making your home life happier as 'Read a good book on the sexual side of marriage'." I had to re-read the enclosing paragraph several times before I realized that Platt's advice was basically, "Read new books."
The biggest problem with the book is that it just feels lazy. Platt constantly references other authors that write better and have more insight into the topics he covers. Bruce Schneier. Vincent Flanders. Eric Sink. It's like watching a bad documentary about sci-fi movies, and constantly getting tortured with short clips from Star Wars, The Matrix, and Blade Runner. At a certain point, you just want to throw the damn thing down and go straight to the source material.
Sometimes, Platt saves you the time and quotes the source material wholesale, as in his section on Po Bronson's spoof "The Seven Habits of Highly Engineered People." Each entry is listed, and Platt explains it all to the reader. As I read this chapter, the introduction to Strauss's "Thus Spake Zarathustra" began to play in my mind. I slowly looked toward the sky as I realized that, yes, if this is what it takes, then maybe I, too, could write a book.
Platt invites readers to join his software quality movement and devise some type of "software seal of quality". The accompanying website, suckbusters.com, is clearly unfinished, so I cannot be too critical of it. However, it's hard for me to resist mentioning that a site about sucky software appears to be written in FrontPage and uses frames.
Is there anything in the book worth recommending? For a seasoned software developer, no. If you want a mature analysis of why software is hard to develop, read Brooks' The Mythical Man-Month or Demarco & Lister's Peopleware. If writing human-usable programs is hard for you, check out the writings of Steve Krug or Jakob Nielsen.
But what about non-technical users? Will they learn why software sucks? I keep trying to imagine someone having an intelligent discussion about bad software after reading this book. I can't. They will probably have the courage to say "software sucks". But these days, who needs to read a 272-page book to realize that?"
You can purchase Why Software Sucks...And What You Can Do About It from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The spectrum of what constitutes bad software is mostly limited to usability, security, and stability. No mention is made of supremely sucky software features like digital rights management, spyware from "reputable" companies, and bundled bloatware. There is plenty of information about these topics that the general public could benefit from, but none is to be found here. To his credit, Platt does mention annoyances like "free registration required" news sites and privacy issues.
The chapters focusing on software shortcomings all have a similar structure. The problem is put into historical context, a reason is posed about why the problem still exists, and readers are given advice on how to fix it. The insights into the world of software development are limited and stereotypical. In Platt's world, programmers are ego-driven, awkward geeks who only care about creating whiz-bang features at the expense of usability and usefulness. They're elitist and lazy, passing off responsibility to the user via confirmation dialogs and convoluted options menus. They go to tech conferences and pay more attention to the amazingly realistic software rendering of a bikini babe as opposed to talking to the real woman standing right next to them.
Of course, stereotypes are often true for a subset of any population. But Platt's characterizations are shrill and condescending, often reading like they were co-written by Comic Book Guy and Ann Coulter. Little mention is made of anyone else in the development process besides programmers. (Because, you know, in the history of the world, a marketing manager has never had a bad influence on a product. Nope, never happened).
Usability labs are cited as a great way to improve product quality. Great, but who is in charge of funding usability labs? Not programmers. Most programmers I know would love to have their product improved upon with usability testing. And by the way, if you think the previous sentence lacked supporting evidence, get used to it, because that's the level of research that is found (or not found) throughout Why Software Sucks.
The examples are typically shopworn (Yes, the Google homepage is simple and easy to use. We get it. Lord Jesus, we get it.) or trivial. UPS.com is constantly scorned throughout the book because it asks the user for their home country instead of detecting it via the user's IP address. Starbucks.com commits the deadly sin of defaulting to a 5-mile radius for it's store locater instead of just listing closest stores. Yes, these are annoying faults, but are they really the best cases out there?
Readers are given advice on how to improve software quality, and it all boils down to boycotting bad products, sending letters to companies, and spreading the word among friends. If you need more firepower, you're out of luck. How can I get my employer to use better software products? Or my local government? Can I leverage accessibility and usability laws in the fight against bad websites? Are those crickets I hear?
In the second half of the book, Platt takes a turn towards sociology and tries to explain the environments that geeks gravitate to. His prime example is the Microsoft Tech Ed conference, which, given the way he describes it, doesn't sound very different from any other kind of conference. Marketing bozos, gratuitous tschotchkes, after-hours drinking by the speakers...it could just as easily be the annual gathering of the Coffin Retailers of America.
Platt has mastered the art of the non sequitur. Theorizing that maybe the problem with software is that the field is too male dominated, we are told that, "Many people think that the recent child molestation and cover-up scandals in the Catholic church stem at least in part from the hierarchy's all-male culture." Gotta love those "many people" and what they think might "in part" be a cause of a problem. "Like Israel, Microsoft is finding out that being on top isn't quite as much fun as it looked like it would be when it was on the bottom." Does that make Apple the PLO? My favorite example is when Platt draws inspiration from How To Win Friends and Influence People. "Dale Carnegie lists rules #7 for making your home life happier as 'Read a good book on the sexual side of marriage'." I had to re-read the enclosing paragraph several times before I realized that Platt's advice was basically, "Read new books."
The biggest problem with the book is that it just feels lazy. Platt constantly references other authors that write better and have more insight into the topics he covers. Bruce Schneier. Vincent Flanders. Eric Sink. It's like watching a bad documentary about sci-fi movies, and constantly getting tortured with short clips from Star Wars, The Matrix, and Blade Runner. At a certain point, you just want to throw the damn thing down and go straight to the source material.
Sometimes, Platt saves you the time and quotes the source material wholesale, as in his section on Po Bronson's spoof "The Seven Habits of Highly Engineered People." Each entry is listed, and Platt explains it all to the reader. As I read this chapter, the introduction to Strauss's "Thus Spake Zarathustra" began to play in my mind. I slowly looked toward the sky as I realized that, yes, if this is what it takes, then maybe I, too, could write a book.
Platt invites readers to join his software quality movement and devise some type of "software seal of quality". The accompanying website, suckbusters.com, is clearly unfinished, so I cannot be too critical of it. However, it's hard for me to resist mentioning that a site about sucky software appears to be written in FrontPage and uses frames.
Is there anything in the book worth recommending? For a seasoned software developer, no. If you want a mature analysis of why software is hard to develop, read Brooks' The Mythical Man-Month or Demarco & Lister's Peopleware. If writing human-usable programs is hard for you, check out the writings of Steve Krug or Jakob Nielsen.
But what about non-technical users? Will they learn why software sucks? I keep trying to imagine someone having an intelligent discussion about bad software after reading this book. I can't. They will probably have the courage to say "software sucks". But these days, who needs to read a 272-page book to realize that?"
You can purchase Why Software Sucks...And What You Can Do About It from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Did that guy ACTUALLY relate child-molestation cases in the Catholic church to poor software quality?!? Wow... just... Wow...
To summarize, they generally lack action and a good love interest.
It must have been something you assimilated. . . .
Heh... the review makes a good point. The website for the book is incomplete and done in FrontPage 5. I'm serious when I say this... I'm gonna write him an e-mail and tell him how much his website sucks. Perhaps others should follow his advise and do the same.
Similes are like metaphors
software sucks because it's a very literal realization of a detail-oriented person's conceptulization of a process as related by at least one intermediate person (or, more likely, a committee of people).
If you take a programmer with no practical knowledge of the context in which the software is supposed to work, don't give them time to learn anything past the very basics, keep them at a distance from the people who will actually use the software, and have all the decisions on the functionality of the software, the timeline for delivery, and prioritization of the various parts of the software made by a committee of middle managers, marketing wonks, and executives you will get exactly the kind of sotware we all know and hate.
The best examples of software that I've seen were either written by a programmer with experience in a certain field working closely with an expert, or someone brilliant in a particular field who had a great idea and then picked up programming in order to implement their idea.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
A recent of example of why software almost sucks:
Software sucks because people get stuck in a mindset. Until last week, I thought that Thunderbird was easy to configure for email. Here is what I do:
- Enter incoming mail server name
- Enter login name and (optionally) the password
- Click ok
- Try to get your mail
- Now go back and try it with the SSL option
- Now go back and try it with the TLS option
- Now go back and try it with "Use Secure Authentication"
- Repeat combinations of the above until you find the most secure one that works
Recently, my wife got a Mac. Here's how to do it in "Mail" for the Mac:
- Enter incoming mail server name
- Enter login name and password
- Click ok
"Mail" connects, tries each possibility, and sets it to the most secure option that works.
Now until I saw this, I never even considered the possibility. Now, it seems quite obvious. Unfortunately, I have to ding them on this - if the password is wrong, it hides the error message from you (you get something generic like "connection failed"). So I spent two hours trying with the wrong password while damning Apple because I thought the problem was that their nifty "do it automatically" approach.
So let's review:
- Don't get stuck copying the way other things do it. Do it right.
- Make it easy by only asking the user for the things the user is responsible for.
- Don't hide information (such as settings or errors) from the user (yes, in "Mail" you can go back in and see what settings it picked)
If we could get the above three right, life would be much easier.
Javascript is required for simple hyperlinks to work. That's some quality suckiness right there. You really have to go out of your way to make a plain old hyperlink non-functional.
Edith Keeler Must Die