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. . . .
The book sounds terrible, but I will agree that a large number of developers are blinded by egoism.
Spend a little time and you will find countless projects dividing talent among slightly different versions of the same thing and developers who really don't understand their users and don't want to understand them. "If they want something to be different, have them code it themselves!" is a tired refrain, but it points to a mentality of software for the developer, not the wider audience. While I'll admit that it can be good to mess around and create something primarily for yourself, when your goal is widespread adoption of your product, it certainly helps to consider what the end user wants to achieve, and what their standards for usability are.
Software development too often gets mired down in pissing contests, personal rivalries, egoism and Not Invented Here Syndrome and makes the developers appear amateurish and unreliable. This reflects poorly on their software, and we are left to hear them piss and moan about how their great app just can't make any headway against an entrenched rival.
Sometimes the competitor uses unethical tactics, sometimes users are just afraid/can't afford change. Other times however, the developer just wrote the software for themselves and never took the end market into account.
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
It really comes down to:
1) Features
2) Cost
3) Time to market
4) Quality
Choose any THREE of the above.
Most software vendors do not compete on quality, they compete on one or more of the other three aspects. In SOME markets (telecom, avionics, etc.) - quality is more important. Releases tend to come less often and tend to be more expensive. Want quality software? Be willing to wait longer and / or pay more for it.
[Insert pithy quote here]
That is, of course, no reason not to try and make it more reliable - we'll never be perfect, but that doesn't mean we can't try to be better.
Sure, you will never have something work for everyone exactly as they would want it to - if you're going to count missing features as failures of the software then inevitably you're going to find everything inadequate. What software developers could, very reasonably, be aiming toward is, if not guaranteeing that everything will work exactly as desired, at least providing some certification as to which bits they are pretty damn sure will always work as expected (and under what extreme conditions, such as hardware failure or OS bugs, they might condone failure). A word processor might not have all the features I could imagine wanting, but that doesn't mean having a guarantee that, barring hardware failure, it won't ever corrupt a file I'm working on wouldn't be nice.
Craft Beer Programming T-shirts
The reason software sucks is too simple. Software sucks because we don't care. But that doens't give enough material for a whole book I guess.
Really though, it is just that simple. We know how to make software that is reliable and secure. What do people buy? There is your answer.
And now to make sure I piss off everyone lets go beyond just slagging Microsoft since that is like kicking cripples. Macs suck too. Same for Linux, and BSD. All have bugs exposed on an almost daily basis. Why? Because nobody cared enough.
Ok, so what is my solution? Not giving a rats rectum about Windows or Mac limit my rant to Linux (and a bit of BSD). Start with OpenBSD as they are the closest to getting it right. Sure there isn't much in BSD, but what IS there is as reliable as an organization their size can make it. Features be damned, make it work!
So why couldn't organizations which have more resources take that idea to it's logical conclusion? Look people, adding new features before the old ones work is pointless and leads to software that sucks. Step one should be to take the Linux Standard Base and freeze it. Audit the crap out of it for security flaws and close every single bug report. Eliminate every compiler warning. Then look at every package that isn't at 1.0 status and decide what is needed to call it done and then DO it. Then begin moving that line outward. For now the graphical desktop environments probably can't be frozen, but everything underneath can be.
This won't happen though, because NOBODY CARES.
Democrat delenda est
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.
If reviews were written only on books the reviewers liked, that would be one world of biased opinions don't you think?
Moreover, you seem to think that the reviewer is bashing the author/book where it appears to me like a good review and shows a lot of misses in the book itself. As an example, the author categorizes software developers in a very small box a bit too easily IMO.
Yes, I've read part of it, it is extremely short-sighted and won't help the supposed 'target audience' you talk about, in knowing more. Confuse them more? Definitely.
...regrettably out of print and, of course, now out of date... was Boris Beizer's The Frozen Keyboard: Living With Bad Software.
It is a classic, and well worth reading. And it does not condescend, and is full of good advice that naive users don't necessarily know. For example, don't type unreasonable values into fields... never enter data when the program appears to be busy doing something even if the program lets you do it... things like that.
"How to Do Nothing," kids activities, back in print!
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.
Also, books don't fall out of the sky in final form. They are products developed at companies that wish to make a net profit from them in a fiercely competitive book market. The author of a book intended for the lay public is usually closely managed by the editor in charge of the project in order to insure that the target market is well-served. You need only watch a few hours of prime time TV to glean an idea of how to approach that market. To provide a book that passes muster with SW developers would be a blunder. To hype up pre-conceived stereotypes and stroke the lay reader would very likely prove useful. To drop famous names and quote from their writings, implying agreement with the book's theses, would also be a good idea.
They are trying to sell books, not philosophize at an intellectual café.
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?
To answer the first question, unless you're in the management or IT department of your company you CAN'T get them to use better software products. To answer your second question, you have NO BUSINESS telling your local government what software works for them. (And I'm an advocate of OpenOffice over MS Office for home use as well as using it at my job, but I work in IT) And to answer your third question, you can try, but you have no guarantee of succeeding, nor should you. You didn't pay to have the websites developed, therefore you have no say. In an ideal world people would just do the right thing. But this is far from an ideal world.
It seems to me that your rant (not really much of a review at all) is misplaced against this book. You're railing on about his attack on programmers but not paying attention to the fact that end-users and not coders are the target of this book. They could give a rat's ass about DRM because other than some minor inconveniences and some extra costs, DRM is transparent to them. We have a right to be angry about DRM because it hobbles programmers from being able to actually take advantage of whiz bang new possibilities afforded by upcoming technology since DRM imposes artificial restrictions on us. Joe Average will NEVER "get" that.
I agree with you in that he focused on the wrong stuff to a degree. He got it right as far as the average user goes. But if he was really going to show them the inside of the sausage factory (which I find disturbingly phallic mind you), he would point out that most people writing software today have no business writing it. All the slick IDEs that have been unleashed on would be coders and web developers has resulted in everyone and his brother being a "programmer". There are people developing applications and web sites out there who don't even know what structured programming or OOP are. They have no concept of the basics when it comes to writing code. Most of it is pieced together crap without reusable code even factoring in. It's beyond crufty. And THAT is why software sucks today.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Seriously, that's basically it. It's perfectly possible to write software that doesn't suck- people do it all the time. (See pretty much anything written by JPL, for example)
But it costs. It costs for the good management&development team to decide exactly what the spec will be. It costs for good, experienced programmers to write solid, mantainable code. It costs for QA and UI people to go over everything with a fine tooth comb. It costs time to get it all right, and you're not going to get every wiz-bang feature because that would cost even more.
99.9% of users simply aren't willing to pay for that. The few that are live in niches where an accident is simply not acceptable. (See JPL, above, and even then they aren't perfect: see Spirit for an example) The rest of us settle for the likes of Windows and Office- lots of features, mostly works, ok UI simply because the perfect option would have a 1/10 the features and cost 10x as much.
"Seven Deadly Sins? I thought it was a to-do list!"
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
Oh dear, marked as flamebait. I guess our slashdot overlords can't take criticism.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
Software sucks because the costs of it sucking fall on the user, not the manufacturer. That's hasn't been true of automobiles for several decades now, and cars have gotten much better. When was the last time your car died on the road?
Many years ago, I was at Ford Aerospace when the Ford EEC-IV electronic engine control unit was being developed. In that unit, the program was permanent; it was in a mask-programmed device, and could not be changed without replacing the entire unit. Very substantial resources were devoted to insuring that there were no bugs that could cause cars to fail on the road. There was huge fear of a recall; if something had gone wrong, most of the Ford cars on the road would have to come back to a dealership for CPU replacement. There were old engineers at Ford who didn't want a computer to have direct control of the engine. Tweak the spark timing a bit or adjust the emissions valves, like the earlier models of engine control, perhaps. But actually fire the spark plug directly from software? That was radical. So everyone involved was paranoid about bugs.
It worked. Twenty years later, no bugs have been found. There was never an EEC-IV recall. The EEC-IV is still popular with enthusiasts. You can even download the code and run it in an emulator. I still have a 1985 Ford Bronco with its original EEC-IV, and it runs fine.
If Microsoft had to face the possibility of bringing every PC with Windows on it into an approved Microsoft repair center for a software update at Microsoft's expense, Windows would not crash. It might not do as much, but critical components of it wouldn't fail disasterously.
And that's why software sucks.
You can't use the keyboard to navigate to all the icons in a Windows application's toolbar? That sucks.
Your car stereo doesn't have a two-cent audio-in jack? That sucks.
Your cellphone's 'send to voicemail' button is right under your thumb when you flip the phone open? That sucks.
Your kids' school sends students home early when they don't have a class in the last period, but there's no school bus? That sucks.
Your TV reception is better than your cable reception, because there's an amplifier on your line that's flooded every time it rains? That sucks.
Your town built a bridge and created a stagnant pool right where the ouflow from the slaughterhouse hits the river? That sucks.
What makes anything think that bad design, screwed up decisions, and lousy implementation are unique to software?
Mel Gibson? Is that you?
If you don't like a book, and you're not its target audience, then put it down and don't review it.
I found the review to be informative. I have to believe that the intended audience is programmers, no matter what the author says. Do you really think that non-programmers will buy such a book? Surely they are more interested in the latest novel, than in yet another vanity piece. The points that the book made needed to be addressed, and I thought that the reviewer did so.
It's a poorly written and misleading book; that's plain. The review saves those of us inclined to buy it from doing so. I doubt very much that the slashdot audience is composed of non-technical, mid-level managers. The review was intended for us, and it served the purpose.
The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. (Mark Twain)
Yeah it is too bad there are a lot of bad software shops with a lot of bad managers running a lot of bad projects.
But seriously it does not require perfect requirements or a perfect master. The key is to have requirements, including test cases and success criteria. Things certainly change but it shouldn't be the usual "change the code before even determining if there really is a problem since you have no requirement to compare to , hope it does what it's supposed to do, write a test based on the code that, unless the developer is an idiot, has to pass, because it is based on the code he wrote after all, and then maybe, and this is a big maybe, go back and update the requirements" but instead should be "determine the problem, review the problem, update the requirement, write the tests, determine completion criteria, distill the subject mater into terms the developers can understand, which isn't that hard, all things can be distilled to binary comparisons after all, write the code and the test the code based on the aforementioned tests."
You will find out that if you do what people say and not what you think they mean they will start to tell you what they actually mean and therefor reduce the amount of guess work to zero. So if whoever is in your analyst role can't convert business requirements into technical requirements best get yourself a new analyst. This really isn't that much work, but it is certainly more effective (cost, time and quality) than not having decent specs and people specialized in what they do. And if you don't believe me you can do one of two things, read someone like Brooks, or honestly give it a try (took about a year to turn one very disorganized shop around and it is no the single most efficient place I have ever worked).
Having developed Genetic Research software I can tell your from experience, a little knowledge is dangerous and having enough to be worth while would have most developers going back to school for another 6+ years, which is just about enough to forget how develop and at the very least be a generation behind the latest technology and advancements in development.