Why Software Sucks 257
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.
Sounds Familiar (Score:1, Insightful)
Well (Score:4, Insightful)
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.
His website sucks (Score:4, Insightful)
Software developers upset that they suck... (Score:0, Insightful)
Who writes the code? Who designs the software? SOFTWARE PROGRAMMERS!
(They don't get to be called engineers, because in order to be an engineer, there has to be a science behind the design instead of people randomly banging out code.)
Yes, software sucks because the people writing it suck. There is good software out there - it's hard to find and very expensive, but it's out there. Unfortunately since just about any monkey who can bang on a keyboard is allowed to program, there's also a lot of bad software out there.
It's not marketting's fault and it's not sales' fault that software sucks - they don't design it, they don't create the bugs, they don't create the features.
The only people who can possibly take the blame are the PROGRAMMERS.
Just like the reviewer blames the author of the book for the book sucking and not the publisher, the only people responsible for software quality are the monkeys that write it. Stop playing the blame game and accept responsibility for poor software already!
Re:There is truth in this book (Score:3, Insightful)
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.
Simple explanation (Score:3, Insightful)
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.
Re:Bleat, bleat, bleat.... (Score:4, Insightful)
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.
Re:Simple explanation (Score:4, Insightful)
Software doesn't suck because people don't care. Workers doing their job may or may not care, but certainly the company has some stake in the success of the product (which is somewhat correlated to its quality), and will thus "care" to some degree. But certainly many open-source projects only exist because the people care. So it is not that, in my humble opinion.
It is all a matter of priorities and engineering. I'm sure every geek has thought of what you suggest at some point: "If only there were infinite time and we could really refine this code, we could make it *perfect*!" But the truth is that perfection is impossible, because it must meet conflicting demands. To be perfect it must be rock-stable yet somehow incorporate the latest features and be compatible with the latest and greatest protocols/software/etc. The only way to be compatible is to introduce new code, which inevitably has new bugs, and the cycle continues.
Your proposed "feature freeze" has probably been attempted on some projects, and probably with disastrous results. The problem is that a completely stable, bug-free piece of software that cannot interpoerate in a modern environment is worse than a somewhat bug-ridden piece of software that *does what I currently need it to do*!
Personally I think developers care enough. Part of the problem (as the book appears to point out) is that people accept/buy sub-standard products when viable (better!) alternatives exist. Boycotting is indeed useful in such cases.
But overall software design is hard, and it will always be an engineering challenge, where the final solution is never intended to be "perfect" but rather to satisfy some user requirement, while using a set amount of time and development effort. This is true of both commercial and open-source software.
Just my opinion, of course. I'm not an expert in software engineering.
Comment removed (Score:3, Insightful)
Re:Bleat, bleat, bleat.... (Score:3, Insightful)
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é.
Comic Book Guy Indeed... (Score:4, Insightful)
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.
Re:His website sucks (Score:4, Insightful)
Suckbusters.com sucks bad (Score:5, Insightful)
Why everything sucks. (Score:4, Insightful)
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?
Re:I don't believe it... (Score:3, Insightful)
Europeans are more sophisticated.
The US is evil.
Men are Evil.
Christians are Evil.
It is just the flip side of the extreme right dogma.
The US is always right.
Atheists are evil.
Ecologists are communists wanting to trade jobs for trees.
I am so sick of the Google home page being held as an example of usability.
It has one function. It has almost the same user interface as locate!
Yes I like Google for searches but good grief people I don't find Google's interface brilliant as much as I find it a simple interface for a simple function.
Re:Simple explanation (Score:3, Insightful)
Just because you don't think programming has any real science behind it doesn't make you right. Writing effective, efficient algorithms is a decidedly complex task, and given the size and the scope of many of the projects we work on, it's a miracle any of it ever happens at all. Sure, engineering a building is difficult. But it is also a very old problem that has been solved over and over again in the past. We know how do design buildings now. It's certainly not simple or easy, but it's a field where new challenges are relatively rare. Contrast this to the software industry, where quite often what's being written is new, and has never been written before. Most of the solved problems have already been encapsulated into libraries, so the bulk of the code being written is completely new territory, covering problems that have never been completely solved.
Sure, some programmers (and probably all of them at one time or another) bang out some off-the-top-of-the-head code without really thinking about it. But don't paint the entire profession with the same misinformed brush.
Re:Why software sucks, really (Score:4, Insightful)
An OS is far more complicated. Linux/Windows/OSX/ etc. needs to support numerous configuration, with various hardware and software. I don't see many cars out there that allow you to go in and add programs or logic to the engine control system (legitimately). There's also big disclaimers saying that the manufacturer cannot be held responsible if you alter your car and it stops working.
If you want your software to be guarenteed to never crash, you build a box of hardware that cannot be changed. You make an OS that cannot be modified. Then you write all your programs on that machine and beat the hell out of them. You basically lock the system from user modifcation.
Of course, that makes for a real shitty product. So we have these customizable boxes with customizeable hardware and customizeable software. Unless you expect MS to test every possible piece of hardware and software, then there will eventually be problems.
And I won't even get into the complexity of the code for the OS itself. How much code is in that EEC module again?
I also notice that you're quick to fire off at MS. I would just like to point out this is a problem with ALL operating systems. I've had windows and linux both crash and take my system with it. It happens.
But given the choice between something fairly stable, flexible, and inexpensive vs. an uber-expensive steel-clad mono-box I'll take the former.
~X~
Re:Why software sucks, really (Score:3, Insightful)
(The book Freakonomics had an interesting illustration of this phenomenon, whereby bank fraud was much lower in countries where banks were responsible for losses due to bank fraud, compared to countries where the consumer was held accountable. Why? Because when the consumer was accountable, he had no power to fix the situation to reclaim his lost funds. But where banks were held responsible, they had both a large interest in preventing fraud AND the ability to get it done.)
Now if I buy almost any consumer good, and I use it in the way it was intended, and if it breaks and causes me harm (financial, physical, or otherwise), the manufacturer usually has a legal liability. Especially if they knew of the defect and sold it anyway. That is a huge incentive to get the product right initially, and to recall defective products when a problem slips through. If my PC software breaks and causes me to lose thousands of dollars in lost data and/or recovery time, I have no recourse against the manufacturer. They have no legal liability, because software is licensed rather than sold, and of course every manufacturer's EULA essentially says "we the manufacturer take no responsibility whatsoever, this software is as-is and could eat your firstborn for breakfast". The manufacturer bears no cost at all for their failure. If I'm lucky the manufacturer will identify the source of the problem after the fact and post a patch on their website.
The best you can get in that situation is to hope that competition forces the manufacturer in question not to suck too much. But often, there is little competition (often by design, through use of proprietary formats and protocols to lock-in users who otherwise would switch to a competitor).
And that is indeed why software sucks. Because the user wants to fix the problem but can't, and the manufacturer can fix the problem but doesn't care enough to do so. This, IMO, is a large part of why open-source has become popular fairly quickly, particularly among corporate users. Because finally, the user has some ability to fix the problems that are causing him harm.