Forgot your password?
typodupeerror

Why Software Sucks 257

Posted by samzenpus
from the because-it-can dept.
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.
This discussion has been archived. No new comments can be posted.

Why Software Sucks

Comments Filter:
  • by commisaro (1007549) on Wednesday October 04, 2006 @04:07PM (#16310853) Homepage
    Did that guy ACTUALLY relate child-molestation cases in the Catholic church to poor software quality?!? Wow... just... Wow...
    • by Rob T Firefly (844560) on Wednesday October 04, 2006 @04:17PM (#16311003) Homepage Journal
      "Now, I know this is hard for you to talk about, so I brought this to help..
      Show me on the doll where the bad user interface failed to make available options navigable."
    • Re: (Score:3, Interesting)

      by flibuste (523578)

      Thinking about it, it makes a lot of sense...

      A church guy buys a PC with Windows.
      The PC runs fine for 2 days, then starts having troubles, pr0n popup boxes, unending ads, etc.
      No divine intervention will have it behave properly like it did, despite the efforts of our church guy
      Violent behaviour follows

    • Did that guy ACTUALLY relate child-molestation cases in the Catholic church to poor software quality?!? Wow... just... Wow...

      Can you show us on the doll where the programmer touched you?
    • by kinglink (195330)
      Children are molested in church because it's all male. Software designer make bad software. Software design is mostly male. Child molesters are the same as software designers!

      I can just imagine the thought process "god after 200 pages they might not hate software designers.. I KNOW! let's compare them to child molesters, people hate child molesters right?"

      At least he avoided comparing us to terrorists.... in this book.
    • The child molester analogy is becoming common enough that it may supplant Godwin's Law.
    • Re: (Score:3, Insightful)

      by LWATCDR (28044)
      Well it is because men are the root of all evil. You know the fundamental truths.
      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
      • Men, in the gender-neutral sense, are the root of all evil. Eliminate humanity, and there's no more evil because there's no more sentience. There's no more good either but that's another story.
  • If software sucks so much, he should just stop using software all together... I'm sure he'll have a lot of fun using his computer without any of that evil software.
  • by fahrbot-bot (874524) on Wednesday October 04, 2006 @04:16PM (#16310993)
    His next book, "Why Books About Software Suck."

    To summarize, they generally lack action and a good love interest.

    • Not only that. Books about software also generally have a number of other problems:

      They go too much into detail. That really kills a story.

      There's seldom a real climax. For the best books about software, after reading it you know all about that software, but that's about it. A story needs a climax to be interesting.

      Books about software seldom have main characters (unless you count the software itself as such, but then, unless it's some sort of AI, a software usually doesn't really make a good main character
  • Well (Score:4, Insightful)

    by Y-Crate (540566) on Wednesday October 04, 2006 @04:20PM (#16311031)
    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.
    • Re: (Score:2, Funny)

      by kirun (658684)
      Programmer infighting is a management issue. The wrongdoers should be punished by being issued a project to be implemented in Microsoft Access. This will ensure that they do not misbehave again.
    • One thing that I have noticed: It's easy to tell a computer what to do. The hard part of programming is figuring out what the hell the computer should be doing. This leads me into the part of what I want to say that's relevan to the conversation here:

      Sadly, usually the users aren't really sure what they want. Or if they are, they have great difficulty in describing it. And their standards of usability are usually "It should be easy to get it to do what I want."

      You see the problem?
      • by Coryoth (254751)

        Sadly, usually the users aren't really sure what they want. Or if they are, they have great difficulty in describing it. And their standards of usability are usually "It should be easy to get it to do what I want."

        You see the problem?

        Yeah, the problem is that we need to work harder on drawing out the user on specifics as to what they want. I'm not claiming that's easy - it is, as you say very hard - but it is at the root of many problems in software development. Usually the issue comes down to either poor c

    • by AVee (557523)
      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 widesp
    • by geekoid (135745)
      I've spent a lot of time, and I find that attitude to be in the minority.
  • I was reading this wondering what "non-tech people" would read a book like this or why Addison-Wesley would publish it. Perhaps it's supposed to be a Comic Book Guy-ish* , self-deprecating, humorous look at programmers? It sounds pretty unfunny, but as this morning's paean to tedious "Discordia" stupidity demonstrates, there's no accounting for what nerds will find funny.

    * BTW, Ann Coulter? Huh?

  • His website sucks (Score:4, Insightful)

    by not already in use (972294) on Wednesday October 04, 2006 @04:20PM (#16311037)
    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.
    • by AVee (557523) <slashdot@aveeFORTRAN.org minus language> on Wednesday October 04, 2006 @05:08PM (#16311823) Homepage
      The site is in fact a nice demonstration of a some of the real reasons software sucks:
      • Because it is released before it is ready for example. And because we tend to stick to the old stuff, even when we know it is failing (like frontpage 5).
      • Because we believe all the marketing lies (Someone spend a pretty penny on frontpage and just look how wonderfull the result is...)
      • Because we fail to actually learn about, or even slightly investigate into the things we are planning to do (like learning to build websites, not firing up the first application that comes to mind and start clicking).
      • Because we believe everyting that made with on a computer is easy to do (Sure, I can build that website).
      • And of course, because the wrong people are making the important decisions (whoever decided frontpage was a good idea was clearly not capable to take this decision, same goes for the person who did the release planning for the book/website).
      So there is something to learn from this book after all ;-)
  • Platt flaunts his geek cred, all the while implying that he's not one of those geeks.

    Always sad to see a geek in denial. Embrace your geekdom, my brother! Revel in its glory!
    • Well, look-a-here, Hershel. We got us one of them self-hating geeks. Nothing I hate worse than a geek who doesn't appreciate his own rich heritage.
  • It is our computer, our desktop, our disk drive, our internet connection, my start up process. Just becuase I am installing the software does not mean the installer can install anything it wants and usurp all resources.

    We need something like an installation controller. It would back up everything and monitor the installar and log every change to registry, disk, startup processes, changes to drivers, default handler assignments and everything. Then present to the user a simple standard user interface and a

    • We need something like an installation controller.

      Or just have a middleman who maintains a library of software packages that have been reviewed (in some cases, audited rather thoroughly) as being generally safe and what they appear to be, makes sure the packages work together, occasionally checks to see if updates and bugfixes are available, etc. The people must have expertise with the subject matter, have the users' interest at heart (!!), and have a reputation that can be lost if they screw up and be r

    • We need something like an installation controller....present to the user a simple standard user interface and allow the users to check and uncheck to allow and disallow changes.
      This is basically package management. Every usable modern operating system has it. The lack of package management, amoung other things, makes Window$ hopelessly broken.

      Debian/Ubuntu: dpkg/apt and synaptic
      Red Hat/SuSe/LSB: rpm and YaST or yum
      Gentoo: portage and emerge
      IRIX: inst and swmgr
      BSD: ports/pkg
      HP-UX: Software Distri
    • by geekoid (135745)
      Or just a log you could lok at afterwords, and rollback out of.

      This is exactly why I have walways said the registry is a good concept that can not be implimented without causing grief.

      Go back to the one directory for a product that contains everything it needs.

      I am still waiting for my prize for telling MS about dll hell before the implemented it. Seemed like an obvious outcome to me.

  • When we need a book to tell us that software sucks, that sucks.
  • by rlp (11898) on Wednesday October 04, 2006 @04:26PM (#16311149)
    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.
    • by Coryoth (254751)
      Given the review it seems that the book views "lack of features" as a bug, so really it is even worse than you suggest - you can produce a quality piece of software by dropping a few features and you will still be in the firing line of the book author.
  • Software doesn't suck. It's great and has never been better than it is right now...well except for Microsoft software, anyway. Business, finance, transportation, communications, data management, entertainment, etc. are all incredibly enriched over what they were only 10 years ago because of...yes, software. The author is uninformed, misinformed or unexperienced or something.
    • by joto (134244)

      Business, finance, transportation, communications, data management, entertainment, etc. are all incredibly enriched over what they were only 10 years ago because of...yes, software.

      Definitely. At my workplace we can now sit behind our PCs and send these funny email-jokes to each other, while continuing to be even less productive than before. This is called improvement. Hopefully we can soon start working from home, so we can sit at home and send funny joke-emails to each other from there instead. I'm su

  • Simple explanation (Score:3, Insightful)

    by jmorris42 (1458) * <jmorris@beaHORSEu.org minus herbivore> on Wednesday October 04, 2006 @04:33PM (#16311245)
    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.
    • by kebes (861706) on Wednesday October 04, 2006 @04:51PM (#16311497) Journal
      I'm afraid I don't agree with your explanation.

      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.
      • by jmorris42 (1458) *
        > It is all a matter of priorities and engineering.

        Thanks for making my point. It IS a matter priorities and reliability and security aren't very high on the list in the software business. It IS a priority in every other engineering discpline, i.e. the ones where you have to be a real engineer. When people design a building there are a lot of conflicting priorities, exactly like in designing software. But reliability IS NOT NEGOTIABLE. Buildings do NOT fall down on a regular basis and when they do p
        • Re: (Score:3, Informative)

          by AVee (557523)
          And so is rocket science. But rocket scientists try not to put people in a rocket until they are pretty sure the bugs are worked out. Same for airplanes. A modern Boeing airliner is far more complex than GNOME but jets don't fall from the sky on a daily basis.

          Rocket science happens to include quite some software engineering and Boeing happens to employ quite a few developers. This goes to prove your point even more, when it is important enough, when we care (pay!) enough to get it right it is perfectly p
        • by kebes (861706)
          Thanks for making my point.

          Indeed! I mostly agree with what you're saying. However it's worth keeping in mind what the objective of a given engineering project is. The goal of a building is to continue standing and house people. The goal of a bridge is to withstand the load of the traffic across it. Failure to do so costs lives.

          However in software the priority is to get work done. When software crashes, people don't die. Money is lost, but that's about it. Even security flaws don't lead to deaths.
        • Re: (Score:3, Insightful)

          by creysoft (856713)
          You're using a false analogy. Buildings can and do frequently have substantial problems. Asbestos, improper wiring, faulty plumbing, foundation problems, poor space planning, etc. Furthermore, many of these problems cannot be fixed at all, but must simply be lived with, worked around, or ignored. There's no real software equivalent for a building collapsing. I guess the closest you could get would be a program crashing and FUBARing the entire system it runs on, which happens almost never with professional s
    • by Khomar (529552)

      There is a disturbing trend that I have been witnessing in software development -- especially web applications. A lot of effort is being directed into making the developer's job easier or faster at the expense of a better user experience. Toolsets are being developed that make it easy to produce a functional UI in a very short period of time, however the end result is bloated and inefficient -- not just in code execution but in user experience. The interface is not tailored to the user's needs (making fr

  • It's Easy... (Score:5, Interesting)

    by TheWoozle (984500) on Wednesday October 04, 2006 @04:33PM (#16311255)
    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.
    • Re: (Score:2, Interesting)

      by Magnusite (526038)
      Please Mod Parent up..

      Someone already suggested that the ego of the programmers is the largest cause of bad software. In my experience, the need of the middle managers and marketing wonks to demonstrate their superiority is a major part of the problem. Most will come up with off-the-cuff ideas at "bull session" creative meetings and then use all the political wherewithal they have to make sure that their ideas are implemented. God help you if more than one of these people is on your project and they have
  • See Sturgeon's Law [wikipedia.org]

    It applies to software and books...
  • by dpbsmith (263124) on Wednesday October 04, 2006 @04:35PM (#16311287) Homepage
    ...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.
  • by MobyDisk (75490) on Wednesday October 04, 2006 @04:37PM (#16311305) Homepage
    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.
    • Re: (Score:3, Insightful)

      by toadlife (301863)
      The Mac way sounds awful. Does it automatically select POP for you and clear out your mailbox the first time you connect? I would be PISSED if it did that.
      • The Mac way sounds awful. Does it automatically select POP for you and clear out your mailbox the first time you connect? I would be PISSED if it did that.

        No, it asks what type of account you are creating, POP, IMAP, or .mac. It actually works very well in that people who don't know what they're doing can easily create a working e-mail account and it will be as secure as possible. It is a little less nice if you know exactly what you're doing, but if that is the case, you'll figure it out pretty quickly.

    • by AceCaseOR (594637)

      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

      For the record,

    • by slamb (119285) *

      "Mail" connects, tries each possibility, and sets it to the most secure option that works.

      Really? For me, it's always made me enter my credentials, then attempted to send them across the Internet in plaintext, complained that it didn't work[1], and then on the next tab, given me an SSL checkbox. I've always thought of Mail.app's configuration as incredibly stupid and insecure.

      The proper way to do it would be to first try SSL and if that doesn't work, prompt the user with suitably scary text ("Secure con

    • by autophile (640621)

      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").

      Well, yeah, but that's because it's Good Security Practice (TM). If J. Random H4x0r knew that the username was correct but the password was wrong, then he knows he's already halfway there. You're not supposed to give away that some of the information is right, but some is wrong. You're just supposed to say, "No. Try Again."

      See, for example, IETF

  • I think software is so complicated that testing every single scenario is way too time consuming, thus unreliability is inevitable. Also, software developer often get requirements and specifications that aren't complete, but are expected to continue on with development anyway. This introduces a lot of usability issues and bad design decisions. Bad software isn't a result of ego-maniac software developers, but organizational and process issues that result in bad decisions being made.

    Of course then there ar
    • by Coryoth (254751)

      I think software is so complicated that testing every single scenario is way too time consuming, thus unreliability is inevitable. Also, software developer often get requirements and specifications that aren't complete, but are expected to continue on with development anyway.

      It is worth noting that the latter leads to the problem of the former. The better the requirements and specification, the easier it is to do more complete testing via automated randomised testing, and extended static checking (which can

    • by geekoid (135745)
      "I think software is so complicated that testing every single scenario is way too time consuming, thus unreliability is inevitable."

      then your software development method is broken.

      "Also, software developer often get requirements and specifications that aren't complete, but are expected to continue on with development anyway."

      The software developers supervisor needs to be pushing back on this situation. Thi includes documenting costs incrued do to poor requests.

      "This introduces a lot of usability issues and
  • Everyone seems to be forgetting the real reason software sucks: all the developers are reading Slashdot instead of coding. Get back to work, you slackers!
  • ....it's written by people.
  • If good software (often this is reduced to good UI design, which really ought to make the problem easier) were easy to write, don't you think somewhere during the past 50 or so years, someone would have figured it out and started a company to do it? And yet I have a hard time coming up with more than a half-dozen applications to which I'd give a score in the top 5-10% for satisfaction. No, I don't mean "more satisfying than 90% of software". I mean "90% satisfying". As in "less than 10% of things I try
  • by eno2001 (527078) on Wednesday October 04, 2006 @05:03PM (#16311717) Homepage Journal
    And I quote:

    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.

    • Which pretty much means that all device drivers, almost any kind of firmware or assembly language code, OS code, networking code, etc., all suck -- by definition. Thanks for clearing that up.

      I kinda figured that was true, 'cause when my computer blue screens and stuff I see a lot of hex numbers and weird crap like that and so that's probably machine language or something so that's why it probably sucked and died and stuff.
  • by edremy (36408) on Wednesday October 04, 2006 @05:07PM (#16311797) Journal
    "Because you're not willing to pay for what it would cost not to suck"

    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.

    • Some of the biggest flaws in Windows would remain flaws no matter how well they were implemented, because they're inherent in the high level design of major components, designs that were chosen for political reasons. bad user interfaces can be replaced. Bugs can be fixed. But there is no way to securely implement Active X as Internet Explorer uses it even if you got the ghost of Turing riding shotgun with Wirth and Knuth as pilot and copilot.

      This isn't anything to do with software development. It's no diffe
  • who thinks that the UPS and Starbucks "problems" have good use? Like the fact that UPS wouldn't always be able to get the correct home country for somebody using a remote proxy or that somebody might actually want to know all the Starbucks locations within 5 miles because that's as far as they're willing to go, but they might be in different parts of that circle at different parts of the day...? No, I'm not trying to make excuses for these guys, and I'm sure that it was really lazy programming, but that d
    • by geekoid (135745)
      Five miles is the absolut farthest someone will drive for a coffee.
      Two blocks is the max walking distance.

      So five miles is exatly correct for starbucks.

      IP can not be relied on 100% to determin location. UPS needs 100%

      Ther are a lot of bad examples, those two were poorly choosen.
  • by kindbud (90044) on Wednesday October 04, 2006 @05:21PM (#16312051) Homepage
    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.
  • by Animats (122034) on Wednesday October 04, 2006 @05:23PM (#16312083) Homepage

    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. [fordfuelinjection.com] You can even download the code [kvitek.com] 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.

    • by Xyrus (755017) on Wednesday October 04, 2006 @09:15PM (#16315211) Journal
      You're comparing an OS to a piece of sofware that was written for a single purpose with known hardware constraints. I'm sorry, but that just simply is not a fair comparison.

      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: (Score:3, Insightful)

        by Stradivarius (7490)
        Fair enough - an OS is probably a lot more complicated than the EEC module mentioned. But the point Animats was making is still valid. The costs of software failures by and large are borne by the users, not the manufacturer, and thus there is little incentive to fix the situation. When the only party with the power to fix a problem has little incentive to do so, chances are extremely high that it won't be fixed.

        (The book Freakonomics had an interesting illustration of this phenomenon, whereby bank fraud w
  • by argent (18001) <peter&slashdot,2006,taronga,com> on Wednesday October 04, 2006 @05:37PM (#16312291) Homepage Journal
    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?
  • There are various theories here (in the book, review, comments) about why software sucks, but none of them seem to make more sense than Sturgeon's Revelation [wikipedia.org].

    Being a developer myself, I'd like to argue that most developers aren't ego-driven and amateurish, but they are governed by Sturgeon's Revelation just same as most every other profession. This is certainly borne out by my experience anyway.

  • 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.

    Do it! If your books end up even half as interesting as your book reviews, then you'll really have something. Good luck!
  • I know why software sucks. Its simple. If you have a physical product, and you make a mistake and need to fix it, it is very expensive to either get back all the broken products and fix them or to make replacements. Thus, you dedicate a lot of resources to make sure there aren't mistakes. With software, it is almost free to provide upgrades and patches. Thus, few resources are dedicated to quality control.

FORTUNE'S FUN FACTS TO KNOW AND TELL: A guinea pig is not from Guinea but a rodent from South America.

Working...