Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Why Buggy Software Gets Shipped 422

Posted by Zonk from the life-is-pain-princess dept.
astonishedelf writes to mention an article in the Guardian about the hard reality of why buggy code is sold on retail shelves. From the article: "The world's six billion people can be divided into two groups: group one, who know why every good software company ships products with known bugs; and group two, who don't. Those in group 1 tend to forget what life was like before our youthful optimism was spoiled by reality. Sometimes we encounter a person in group two, a new hire on the team or a customer, who is shocked that any software company would ship a product before every last bug is fixed. Every time Microsoft releases a version of Windows, stories are written about how the open bug count is a five-digit number. People in group two find that interesting. But if you are a software developer, you need to get into group one, where I am."
This discussion has been archived. No new comments can be posted.

Why Buggy Software Gets Shipped More

Why Buggy Software Gets Shipped

Comments Filter:

  • Windows Software Shop :-) (Score:5, Insightful)

    by Whiney Mac Fanboy ( 963289 ) * <whineymacfanboy@gmail.com> on Thursday May 25, 2006 @10:37AM (#15402026) Homepage Journal
    Typical Windows Software house:
    Vault's backend makes extensive use of features specific to Microsoft SQL Server. Contrary to popular belief, SQL isn't portable.
    *shakes head* and then this:
    Linux and MacOS users have problems over how end-of-line terminators show up.
    Ouch!

    Anyway, I do agree with the author for the most part (its all pretty 101 risk assessment stuff). It is inevitable that software will have bugs in it (especially commercial software shipped to a schedule). This is not really news tho'.

    What I would like to see is some vendor honesty. How about making a list of known bugs available to your customer prior to purchase? (I know, I know, fairly warning a customer is madness, etc etc).
    • How about making a list of known bugs available to your customer prior to purchase?</i> I don't think the Board of Directors on any publicly traded company will allow this. The problem with many traded companies (and I'm using publicly traded companies since MS is mentioned) would be that the company wouldn't likely meet financials. Hence many pouring out shoddy programs. Imagine the trading price of MS if it did ship a list of known bugs alongside their products... I would think consumers would wait

      • Re:Windows Software Shop :-) (Score:4, Insightful)

        by morgan_greywolf ( 835522 ) on Thursday May 25, 2006 @11:51AM (#15402783) Homepage Journal
        Imagine the trading price of MS if it did ship a list of known bugs alongside their products... I would think consumers would wait for a stable product before buying.

        Nonsense. Every major open source project has a complete list of bugs for all versions of their product for all to see, usually right on their Web site, which you can read prior to downloading. For instance, if you click on the Release Notes for Firefox, linked to from the front page [getfirefox.com], you'll see not only a list of known issues in the current production release, but there's a link to their Bugzilla database so that you can read bugs that have recently been filed against it.

        If people would really not buy a software product if they knew about all of it's bugs, then why would they download and install any open source applications? Because they don't have pay for them? Just because you don't pay for a piece of software, that doesn't mean it costs the user $0 to install and use.
      • I've broken MS' MSRPC in a real bad way. There are no ifs ands or buts. I passed the information off to Microsoft instead of passing code to a full disclosure list. I've replicated this over and over, remotely and locally. I know for a fact because of the architecture of networking they will never be able to fix this.

        And yet you can't work a 'preview' button? :)

    • No no no no no no!!!

      It is NOT inevitable that software will have bugs in it.
      By your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.

      This whole fucking "tinkerer" mentality that self important developer assholes have foistered on the rest of mankind, is no different from the self important tinkerer mentality that steam engineers foistered in the 1800's.

      Take solace in the fact that the software development world w

      • Re:Windows Software Shop :-) (Score:2, Insightful)

        by Anonymous Coward
        All bridges DO have defects - a weld may be slightly off-center. A beam might be 1/8" wider/longer than it's supposed to be, the cement covering it may be cracking. The point is that we're all human and imperfect, so therefore the things we create are imperfect.

        It is the job of the engineer (whether for bridges or software) to make sure that the mistakes that ARE made are not the critical ones - the ones that make the bridge collapse or the software crash.

        Until the human race as a whole attains God-hood (wh
        • While it's true that many things in the world do have defects, that's not really the issue.
          That whole article sounds more like "We, in group one, are the cool kids. All the cool kids accept bugs. Why aren't you a cool kid?" It is loaded with the underlying tone of "I'm smarter than you because I accept bugs as normal"

          After the condescending beginning, which assumes that every single person in the world has an opinion on software bugs, the loser then goes on to make excuses.

          "Bugs are inevitable, so w

      • By your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.

        I didn't say all software will have major bugs that lead inevitabley to the collapse of the software. Just that all software will have bugs.

        All bridges have defects too you know - the suspension cables will be slightly uneven, or some features of the fascade will be unsymetrical. Bridge engineers make damn sure there are no structual problems that will lead to collapse (but even they fail sometimes).

        I wish software engineers would be more like bridge engineers as well, but the cost of failure (and the cost of fixing in the event of a failure) are so different between bridges & software that its not likely to change.

      • Foolishness (Score:5, Insightful)

        by daVinci1980 ( 73174 ) on Thursday May 25, 2006 @11:20AM (#15402493) Homepage
        That's foolish. There are bugs in every project of every size. Including bridges. And skyscrapers. Remember the Tacoma Narrows Bridge? [bris.ac.uk]

        Normally, those bugs have low Severity or Frequency (or both). Sometimes they have catastrophic severity.

        Did you know that the twin towers were built to withstand a direct impact from a 707? [punjabilok.com]

        Bugs are a fact of life. They follow from the mantra 'nothing is perfect.'
        • Defects in a product are inevitable. However, KNOWN defects are a different thing altogether.

          In three different positions where I've written software for internal corporate consumption, I've never released code into production with known defects, and I don't see why the fact that a program happens to be shrinkwrapped should make any difference. Our stuff is millions of LOC also, and I'll bet our development times are shorter than most shrinkwrapped software vendors.

          A lot of it comes down to (1) experience
      • It is NOT inevitable that software will have bugs in it. By your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.

        Yes, for any non-trivial software system, it is inevitable. How would you go about testing every-single logic path within a large system? There are tools that do a good job at estimating test-coverage, but it can only be an estimate. For example, if you have a loop that contains even one simple
      • The software and bridges/houses argument is as stupid as it is old. Do you know what the cost of software would be if it had to be as failsafe as you want it to be? You'll be paying several orders of magnitude more than $500 for your copy of Adobe Photoshop if it has to be certified crashproof, and honestly the price just wouldn't be worth it. It isn't that nobody knows how to make nearly defect-free software.. there are companies that specialize in this while writing software for applications where peop

    • Re: Vendor honesty (Score:5, Funny)

      by Medievalist ( 16032 ) on Thursday May 25, 2006 @11:03AM (#15402308)
      What I would like to see is some vendor honesty. How about making a list of known bugs available to your customer prior to purchase?
      Good idea! You go first.

    • The problem with vendor honesty is that it backfires on the vendor.

      Let us suppose that WidgetWorx version 1.1 gets shipped. Inside the package is a list that says, "at the time of shipment, these are known bugs/shortcomings/issues."

      An ambulance service that uses WidgetWorx for their dispatching service, and something goes wrong that leads to a patient dying. Said patient's estate could hire a savvy lawyer who would make a wrongful death claim against the ambulance service for "using a software package with

      • I'm not sure either of your legal premises hold up.

        Firstly, as soon as the ambulance services comes under fire for using a version of WidgetWorx with known problems, they could line up a dozen expert witnesses to testify that pretty much all software has bugs, and it takes someone of the calibre of Don Knuth to produce a complex program that (probably) doesn't (any more). It is therefore unrealistic to expect that any software wouldn't have bugs, even if they weren't disclosed ahead of time.

        Secondly, if

        • However, the ambulance service chose to purchase WidgetWorx even though they knew that it had a list of bugs six pages long, many of which directly affected their ability to perform their key tasks.

          What they didn't do was purchase the X-Widget product from a rival developer, which was released with only one page of known bugs, none of which had any impact on their daily ambulance operations. That's clearly negligent and shows that the ambulance service doesn't care about their clients lives at all.

          The

    • "Cost: Very high. Vault's backend makes extensive use of features specific to Microsoft SQL Server"

      Read: we got embraced and extended all to hell. What do to? Blame SQL! That's right, the language itself! It "isn't portable". Also blame users! "People who refuse to use SQL Server can't use Vault."

      And here's some typical MS morality for you: "I'd probably even patent this algorithm even though, in principle, I believe software patents are fundamentally evil."

      I don't expect bug-free software of any real

    • It took a leaked Microsoft memo to find out Windows 2000 shipped with 65,000 bugs [msversus.org]. Even the author of the memo wrote [zdnet.co.uk], ""How many of you would spend $500 on a piece of software with over 63,000 potential known defects?"

      The problem is with a number that large, no matter how small the proportion is to code size, the backlash would be huge. No potential customer could hear that number and then actually want to buy a copy. I believe they should disclose as much information as possible. But from their perspec

    • Re:Windows Software Shop :-) (Score:5, Insightful)

      by Loki_1929 ( 550940 ) on Thursday May 25, 2006 @11:20AM (#15402494) Journal
      "How about making a list of known bugs available to your customer prior to purchase?"

      There are several reasons not to do this. Not the least of which is simply that most customers don't want to know what's going on inside the application. They want to click "Button A" and have "Box X" pop up and start flashing - or whatever. They don't know that 300 lines of code went into making that happen and they're fine with not knowing that. They certainly don't want to be forced to actually understand what each of those 300 lines of code are doing. Try to explain it to them and watch their eyes glaze over in a hurry. You can try to simplify the explanation for them, but it'll never be enough because they can't grasp the problem without understanding what goes in to making it work; a necessity in understanding why it doesn't.

      The point is that when you get into listing bugs, you have a number of caveats. First of all, in their eyes, you're telling them that the application you're selling them is broken. Sure, those bugs may never actually affect them. They may even be in parts of the code that aren't even used yet because it's part of a feature not currectly activated. But hey, you're selling them a broken program. Remember the Pentium floating point fiasco Intel had to suffer through? What was wrong with their processor? Nothing that isn't wrong with anything ever manufaturered: minor defects that rarely or never manifest under normal operating conditions. What happened when the news got out about the floating point bug that didn't affect more than a hundreth of a percent of buyers - if that? The 'public' went ballistic about it and Intel was eventually forced to do a recall of CPUs that were perfectly functional. Nevermind the fact that AMD and Intel routinely publish a long (and growing) list of 'errata' for their processors that are chock full of bugs. The moment the public got news of a single errata (which, again, didn't even affect them), they demanded replacement "working" products. Are you, as a company, going to expose yourself to that kind of liability?

      Basically, the customer doesn't understand the inner workings of your application, doesn't want to understand the inner workings of your application, and if you try to make them understand anyway, bad things will likely happen to you. People can handle unexpected behaviors (bugs) when they're discovered and a promise is made to make it right (patch, updates, etc). But if/when they get wind that you knew the bug was there, and that there were others? That's a receipe for disaster.

      What geeks/coders need to understand is that we make up a vastly small minority of software users. Unless and until a vendor is selling products to, and only to those who are informed, knowledgable, and intelligent about computer code, you will never see a list of known bugs right on the box. If it's there at all, it'll be made as obscure as possible so that your average Joe can't find it. Why? Because average Joe will go nuts regardless of how inconsequential the bug is, or how much it would push back the release of the product to stamp out all the (known) bugs.

      Personally, I don't blame developers and vendors one bit for obscuring the known problems. When I run into a bug in something like MySQL or PHP, I can find out about it, whereas slightly-above-average Joe (beginner PHP page creator) would have a heck of a time. I find that to be ideal, as I can find the information I need and Joe's not taking up the vendor/developer's valuable time whining about 10,000 bugs he'll never see in his life.

    • When I worked at then Unisys Airline Center in the early 1990's, the defect count for the product we were working on (USAS*CGO, an air cargo airwaybill processing application) had to be down in the single digits before a new version of the product was released, and we delayed the release of USAS*CGO 11R2 for several weeks until that goal was accomplished.

      Customers were also made aware of the outstanding issues, but in our case all customers also had the source code to the application (mainframe software in

    • Re:Windows Software Shop :-) (Score:5, Insightful)

      by colmore ( 56499 ) on Thursday May 25, 2006 @11:52AM (#15402799) Journal
      Reading this made me cringe:

      "All the reasons are tied up in one truth: every time you fix a bug, you risk introducing another. Don't we all start out with the belief that software only gets better as we work on it?"

      Holy shit! I can't imagine being on a team with that attitude? Do you people write tests? There are dependable ways of insuring that changes don't re-introduce old bugs, and if you can't fix one thing without causing a seemingly unrelated problem, you're working with some pretty smelly code.

      There's definitely truth in the statement that the need to use software and the need to eliminate bugs can be at odds with each other once the bugcount is low enough that the product is usable. But... isn't that obvious? How many open source projects out there (without version numbers approaching a known irrational number that is...) can really brag of being bug free?

      BUT this article is a good reminder of why I'm glad the boxed-software days are coming to a close. Software should either be written with a client present or by people who intend on using the product themselves. Trying to come up with a featureset for some vague "target market" is a horrbile way to write software. Software is unique because it is both engineering and design at every phase of its creation... and without set feature requirements and feedback, there's really no way to know if what you're making is well engineered or not. Anyway, don't work in a closedsource / many customers environment... it's bad for the brain.
      • Holy shit! I can't imagine being on a team with that attitude? Do you people write tests? There are dependable ways of insuring that changes don't re-introduce old bugs, and if you can't fix one thing without causing a seemingly unrelated problem, you're working with some pretty smelly code.

        You're new to this aren't you.

        If you can find a way to PROOVE that a less than trivial fix hasn't broken something else, you'd be too busy sailing the world in a multi million dollar cruiser to post to /. - the very fact

  • And lo, there was much rebuking (Score:3, Insightful)

    by linvir ( 970218 ) * on Thursday May 25, 2006 @10:37AM (#15402028)
    I disagree with his grouping. The vast majority of the six billion doesn't give a shit about software bugs. They're primarily concerned with their ability to exchange services and products for money and vice versa, and if they do have free time, they don't spend it fretting about XP's bug count.
    But if you are a software developer, you need to get into group one, where I am.
    Or maybe even better would be for both groups to continue to exist. The Jedi need the Sith, and smartasses who don't worry about bugs need idealistic noobs who find them shocking. This sounds like the case of someone who's managed to become so surrounded by likeminded coworkers that he's completely convinced that his is the One True Way.

    And do we really need that much whitespace [linuxvirus.net] on a news page? I know about that whole '10 words per line' usability mantra, but it looks fucking ridiculous. Why can't all the other website owners just think exactly like me?

    Wow, look at all that rebuking. Do I win Slashdot?
    (IAJAFSS (I Am Just Another Fucking Smartass Student))

  • A separate question (Score:5, Insightful)

    by Southpaw018 ( 793465 ) * on Thursday May 25, 2006 @10:39AM (#15402050) Journal
    The argument about the enormous bug count in Windows isn't really about every last bug being fixed. The article fails to address a separate question: whether you're allowing the public to do your beta testing for you.

    The idea of QC/testing/beta/whatever the heck you want to call it is that you get as many bugs as you can fix while accepting the ones that will remain behind. That's absolutely correct. However, there are companies - like Microsoft - that are notorious for either being sloppy and not getting bugs they should have, or just straight up not caring at all and rushing a product to market that legitimately shouldn't be there.

    The argument can even be extended to good coding practices, like worrying about security fron start to finish rather than after you've entered beta (another well known Microsoft flaw, though they're getting better at it). That reduces the number of bugs to begin with, which in turn gives a better product.
    • Not a fanboy of MS, but they certainly haven't rushed Vista out. I'll bet that they do ship it in s pretty buggy state when it does come out, but they have delayed its launch it is becoming like Duke Nukem Forever.

      Anyway, yes, most people don't care about software, but you also have to look at what the application is trying to do and what you need it to do.

      1) Rules of thumb: The last 50% of a project is spent taking it from 95% to 100% (or really 99% as the case may be...)

      2) Is the software used for medica

      • But the consumers speaking with their wallets doesn't really tell us very much in the software case. There are far more productive and reliable ways to develop software than those typically used in the mainstream. However, until the mainstream catches up and lots of developers are familiar with better techniques and using better tools, all the big name commercial offerings will be as bad as each other, so there's not much for the consumer to vote between.

        Here's an example: I reported a way to crash Paint

  • I propose we call a meeting with Groups 3-12 and 15-20 and see if we can get some kind of real analysis of what Groups 1 and 2 are really thinking.

  • No idea (Score:4, Funny)

    by Unski ( 821437 ) on Thursday May 25, 2006 @10:42AM (#15402076) Journal
    ..why buggy $oftware is $hipped. Can anyone help me with thi$?
  • In many cases, the customer *needs* the software now, bugs be damned. If you don't, your company goes under.

    • Re:Buggy code is sold because it is demanded (Score:5, Informative)

      by drooling-dog ( 189103 ) on Thursday May 25, 2006 @11:13AM (#15402412)
      I'm surprised I had to read so far down to find this, the real reason. Stuff gets shipped because somebody needs to make their numbers, now. Sometimes the survival of the company is at stake, and sometimes it's just an individual climbing the career ladder.

      In a previous life I was in charge of software development for a smallish company whose business was scientific software and systems. To my repeated horror, the CEO and the Sales & Marketing VP would get together and decree - perhaps for reasons that were very compelling to them - that major software packages would be released to customers with no testing whatsoever. Stuff went straight from the compiler to the customer, sometimes even without a cursory walkthrough of functionality. For objecting, we, the software people, were branded as troublemakers and criticized for not being "team players". Once labeled in that way, I would be pretty much ignored any time I had to report that a new product or an update was not ready to ship. Needless to say, I left that company in a hail of bullets.

      To this day, I still laugh when I hear people say that Open Source software can never measure up to "commercial standards". Depends on whose commercial standards you're talking about...

  • The Reason: PHBs (Score:4, Interesting)

    by koweja ( 922288 ) * on Thursday May 25, 2006 @10:42AM (#15402082)
    99% of the time it's because upper managment either promised the customers features that could not be implemented or gave the programmers too little time and/or resources to finish the job. While not software development, I am having to deal with a similar problem right now. We are moving our website to a new CMS system. So we have to move all of the content from our old pages to the new system using a slow, buggy, web based system. In the beginning we were told by IT that we had until June 5 to complete the move, so we scheduled our time accordingly. Things progressed slowly but in time to meet the deadline. Then Tuesday morning we get a call from the assholes in PR that we have to have everything done by this Friday. We just had our remaining time cut in less than half. There is no way we can get done, so the site will be incomplete. PR gets no blame and we look bad.

    • Re:The Reason: PHBs (Score:4, Interesting)

      by __aaclcg7560 ( 824291 ) on Thursday May 25, 2006 @12:05PM (#15402919)
      Then Tuesday morning we get a call from the assholes in PR that we have to have everything done by this Friday. We just had our remaining time cut in less than half. There is no way we can get done, so the site will be incomplete. PR gets no blame and we look bad.

      That's always fun. When I was the lead tester for DBZ: Buu's Fury GBA at Atari, the producer revised the schedule without informing us and I didn't find out until two months after that happened. On top of that, Nintendo insisted that we put in wireless multiplayer capability because the title was coming out the same time as the new wireless adapter was being released. That was a disaster in the making since the wireless API was unproven (even Nintendo had a hard time with it), we didn't get the wireless adapters until a few weeks before we were supposed to code release, and I was planning to leave the company because my boss thought I wasn't working hard enough (I worked 28 days straight before I left, BTW).

      I made extensive arrangements to be the fall guy if this blew up after I was gone so my team wouldn't get fired in my absence. Since I was leaving the video game industry, I wasn't concern about my reputation if I had to take the blame. However, everything turned out as I expected. Nintendo rejected the title for wireless multiplayer bugs, the wireless capability was pulled from the US version (the European version shipped with it a month after the US release), and no one on my team was fired. Well, not immediately. Within a year after I was gone, all my team members were picked off one by one even though they were the most experienced people in the department. I guess my boss found out I reported him to HR for an ethical violation.

  • In my experience, here's the reason (Score:3, Insightful)

    by Weaselmancer ( 533834 ) on Thursday May 25, 2006 @10:43AM (#15402085)

    Managers.

    Specifically, managers who don't know enough about the project (whatever it may be) and make unreasonable promises to their superiors about shipping dates. It seems that the way most businesses are set up reward managers who complete projects on time or early, rather than the quality of the product. As a result, managers tend to rush development teams through their tasks and the end result is a buggy release. And a manager with a bonus check.

    If software shops could change their focus to creating a better release product but with a flexible time schedule...say for instance, rewarding managers for fewer bug reports and service calls rather than completion dates, you'd have an entirely different picture.

  • Nature of Competition (Score:5, Insightful)

    by DuSTman31 ( 578936 ) on Thursday May 25, 2006 @10:45AM (#15402116)

    Regardless of the nature of the software development team, the nature of competition remains the same.

    Stagnation is costly - delaying a product launch drives people to the alternatives (both due to the alternatives updating faster, and due to the lack of progress seen by the outside world).

    Of course, buggy software is costly in terms of reputation, as well, so the end question becomes at what point will the delaying of the release cost us more market share then the remaining bugs will.

    Unfortunate from a purists eyes, but it's just the way things go.

  • There are products available, memprof [gnome.org], Coverity [coverity.com] nessus [nessus.org] which can be used to find and fix common forms of previous bugs. These fix everything from repeating previous security flaws (I note a previously unknown DoS flaw I found in Asterisk's skinny codec ages ago which emulated a bug in cisco call manager exactly, which I found with Nessus), to bad programming, or programming mistakes (Coverity), to memory leaks (memprof). These types of bugs are unacceptable, there are tools out there to detect them DURING

  • bugs, so what? (Score:2, Insightful)

    by ComSon0 ( 473373 )
    We buy buggy cars, houses, and anything else you can think. Nothing with the aim of perfection *ever* gets done.
    So what's the big deal?
    I understand shipping something like bad tires that will eventually kill people should not be done, but anything that does not cause harm or major finantial distress should just be dealt with during the normal lifetime of a product.
    I am an embedded systems developer. We take care of the functionality problems before shipping and work on the corner cases as we move along.
    Th
  • ...Eric Sink, has a interesting piece on his blog about open sourcing Java [ericsink.com]. He says he's a C# programmer now, so kind of a different perspective...
  • I do care about bugs that crash the program, and I really care about those that cause data loss.
    If you knowingly ship code that causes data loss, you are morally responsible for that loss, especially if you don't warn anyone about it.

    Disabling that dysfunctionality is always preferable to destroying customers' work.

  • Real reason (Score:5, Insightful)

    by gowen ( 141411 ) <gwowen@gmail.com> on Thursday May 25, 2006 @10:49AM (#15402163) Homepage Journal
    Because, by and large, no one gets killed when commercial software crashes.

    In those cases where it does; e.g. medical/aviation software, usually embedded people take the time. If aviation software designers cut the same corners (w.r.t. bugs vs. features) that office software designers do, planes would fall out of the air and people would die. So they write well engineered software, in well engineered, fault tolerant languages (lika Ada). (Yes, yes, Ariane, but thats the exception that proves the rule)

    The real reason buggy software is shipped, is because buggy software is accepted by the market, and people will keep buying it, and continue to roll their eyes when it crashes, because they're completely inured to it, and many of them have reached the conclusion that its literally impossible to write robust, stable software.

    It's not, but the profit margins are narrow, and no-one seems to mind (or rather they mind, but keep forking over their money anyway). So no-one bothers to.

    Face if folks, we're enablers.

    • Re:Real reason (Score:3, Insightful)

      by blamanj ( 253811 )
      In other words, companies get away with shipping buggy software because they can. If customers demanded it, the way manufacturers of airplanes and medical equipment did, the industry would be force to respond.

      The problem is, computers are so useful, that customers would (for now) rather put up with bugs than do without. Just as in the early days of the automobile, people would put up with the danger of having the hand-crank break your arm if the car backfired while you started it. Cars were new and had b

  • It's the three M's (Score:2, Interesting)

    by FidelCatsro ( 861135 ) *
    Marketing , Management and Money
  • Articles like these make me sad that slashdot doesn't allow the posting of images in replies. Had this been on fark.com, this thread would be full of Ric Romero [go.com] images.

    Luckily Ric's wikipedia article suggests a textual equivalent..

    "Determining which bugs to fix should take into account some manner of cost-benefit analysis?! Thank you, Captain Obvious!"
  • When I was a lead tester at Atari, there was 3,000+ bugs for Backyard Baseball GCN and less than a dozen open minor bugs when the game shipped. Some people considered 3,000+ bugs to be a high number for a GameCube title. For me, that's being thorough. (Which we had too since the programmers loved inserting phallic imagery into a kids game.) I'm looking forward to seeing how Backyard Baseball 2007 GCN stacks up when it's released next month. My assistant lead tester and I (we both no longer work for Atari) a
  • I would prefer to at least know the things "you" (microsoft, etc. whoever) know that are definitely broken features of the product. I'd like to see "You can't do this, but here's the workaround" and put that info in some kinda place. Programs used to come with user manuals that told exactly how to do things. Now they pretty much don't come with that stuff, which means I should be able to do anything? Nope, some stuff won't work, but no one told me the Proper(tm) way to do it, so I have to go spend anoth

  • because we want it NOW! (Score:5, Insightful)

    by LWATCDR ( 28044 ) on Thursday May 25, 2006 @10:58AM (#15402247) Homepage Journal
    Look at Vista. Everyone is complaining about it not shipping on time. I have yet to hear anyone say. It is a good thing that Microsoft is fixing all those bugs.
    Product ships late because of bug fixes. Why is it taking so long.
    Product ships on time with bugs. Why didn't you fix the bugs before shipping.
    You just can't win
  • The very fact that this discussion arises at all tells me that profitability is of more concern than quality in the commercial software world.

    In the Free Software/Open Source world, that excuse doesn't exist, so what is it? Laziness? Hubris? Apathy?
    • Lack of time for bug-fixing and the virtual impossibility of proving any reasonable size piece of code 'correct'.

    • Laziness? Hubris? Apathy?

      The Holy Trinity is Laziness, Hubris, and Impatience. No patch-pumpkin pie for you.

      All kidding aside, though, impatience and apathy are two sides of the same coin. If you're releasing software out of impatience, you typically don't care about the consequences of not "finishing" the job, as if a software project is ever truly finished.

  • If at first you don't succeed, redefine success.

  • My experience (Score:4, Insightful)

    by bbroerman ( 715822 ) on Thursday May 25, 2006 @11:11AM (#15402397) Homepage
    I work for a large software shop. In my experience it boils down to:

    1. Accellerated schedules created by management / client without development buy-in.
    2. Management cutting development phases in order to get things done faster to meet dates from #1. (i.e. design reviews, code reviews, phases of testing, etc)
    3. Shipping portions of the development off to India teams (in order to save money) who are under trained, and can't speak the same language as the other developers, and who won't ask questions when they don't understand.
    4. Giving development / design tasks to people with no experience in the subsystem that they are being assigned to, because management believes that one developer is as good as any other... we're just bodies...
    5. Churn in employees... Better / more experienced people leaving for better jobs, and noobs coming in to replace them. After a while, you have too many noobs, and not enough older, more experienced folks.
    6. Colleges not training people on common coding errors, proper design principles, good design patterns, proper testing and documentation strategies, etc.
    7. The old addage: Too many cooks spoil the broth. Some times, there are too many senior developers, architects, etc. workign on a design, an they all have their favorite ways of doing things. Many times, even within a single subsystem, one senior person will move to a new project and a new one will come in, and want to change the process / design to fit his style... and usually at the last minute...

    Now, as to why bugs don't get quashed quickly:

    1. Lack of enough informatin from the person experiencing the problem to allow development to recreate the problem.
    2. High complexity of the systems involved.
    3. Bad library design / separation of concerns / encapsulation, etc. means that a small bug in some unrelated libarary can cause problems where you never expected them.
    4. Developers who aren't experienced enough with the code / subsystem to be able to find said small bugs. (i.e. see number 4 and 5 from last list).
    5. Developers who aren't given training and experience in the proper use of debuggers, memory checkers, etc. (how many college hires out there really know how to use dbx to track down a bad pointer in the free list?)
    6. Too small a staff, too much to do.

    I see each of these every day!
  • People do stuff because they can do that stuff.
    Ideally they do it because the trade offs are acceptable.

    In software there is some that is very buggy, some that is nearly bug free. This is mostly driven by what the customer is willing to tolerate.
  • It is better to ship a product with a known quality level than to ship a product full of surprises.

    So, if all the known bugs were fixed, then the product would ship but be full of surprises (since we assume it has bugs we don't know about).

    But if you don't fix the known bugs... the product would ship full of bugs and surprises?

    hmmm...

  • Although Mr. Sink makes good points about the need to ship products with a certain level of minor bugs and do a constant analysis of priorities to continually improve a product, which may lead some minor bugs always open, original architecture design has a big impact on the ability to fix bugs.

    For example, Mr. Sink's two bugs that he cited show two things:

    1. Improper design of the business logic to database connection by locking themselves into a closed-source, expensive, proprietary database system and usi
  • It's that so many companies ship with flaws that would be unacceptable anywhere else.

    Would you ship a doorknob for an outside door that could have the lock so easily breached that it's as simple a matter as inserting a slot screwdriver into the keyhole and turning?

    That's what gets shipped by many companies- those sorts of flaws.

    And it's the mentality of the first group (The "there's always going to be bugs" crowd he's talking about..) that causes the stuff to ship that way. Sure, there's going to always be
    • Would you ship a doorknob for an outside door that could have the lock so easily breached that it's as simple a matter as inserting a slot screwdriver into the keyhole and turning?

      Bad example. The house I bought last year came with high-end doorknob hardware that failed a few months after I moved in. The knob was probably a couple years old, and I had no receipt for it, but I figured I'd call the manufacturer to see if they'd replace the broken part. They said that there was a recall of that part due to

  • How about Group 3? (Score:4, Interesting)

    by dpbsmith ( 263124 ) on Thursday May 25, 2006 @11:18AM (#15402468) Homepage
    Group 3 consists of people who acknowledge that fixing all bugs is impossible, and that judgement is necessary in deciding which bugs need to be fixed... but nevertheless contend that within the personal computer software culture in the United States, these judgements consistently err in the direction of shipping software with too many bugs.

    The personal computer software culture in the United States is much like that of automakers in the United States circa the sixties, who insisted that the low quality of U. S. autos was the result of the best and wisest judgement... and that public toleration of low quality, as reflected in good sales and profits, validated their judgement.

    Good sales and high profits, that is, until overseas competitors began to ship high-quality cars to the U. S.

  • Gears of War (Score:2, Interesting)

    by Unkynd ( 977089 )
    Did anyone see the MTV special about the new XBox 360 game Gears of War? At the end of it, Bill Gates walks up to the Lead Developer (atleast i believe he was the lead), and basically says "So, you are gonna have this ready by August, Right?"... The developer reluctantly agrees that it will be ready by August. Bill Gates responds "Great, we are counting on you." Talk about pressure to get a product out. Can you say buggy release?
  • The problem is that some people percieve that giving people buggy software is somehow unacceptable. When you look at reality, this is far from the truth. People favored Ubuntu over Debian because they felt Ubuntu was newer. People intentionally run ~86 in Gentoo because they care more about newer software than the bugs that might contain. People constantly enter public betas to try out new software. Look at the number of people running Vista on their primary desktop. I'm sure you can come up with plenty mor
  • I can't quite place my finger on it, but if the author is attempting to say that the major software companies that tend to release buggy, shitty software on a regular basis are being responsible corporations, he's full of it.

    Yes, products should ship with bugs. Creating a bug free product isn't worth the time/investment. If you get 95% of the way to done, and the remaining 5% is going to occupy 70% of your budget, don't bother.

    At the same time, software engineering is NOT more sophsticated than, say, aerosp
  • The internet makes patching software a breeze.

    Do you remember back to a time when virtually NO software / games had major bugs? Yeah, that's because patching software by snail mail with floppy discs was a costly and unpractical nightmare, so you had to get it right the FIRST time.

  • One thing which immediately struck me was that the author seems unaware of a key software engineering principle: Reducing design complexity reduces the number and severity of bugs. By now, we all know that there are tradeoffs between complexity, time, and features. However, all other things being equal, some people and organizations consistently produce better software than others. Consider, for example, Linux and Windows. The key reason Linux is more stable and more reliable than Windows is that the process which produced Linux is inherently better at catching and correcting flaws than the one used to produce Windows. Anyone who has ever had to commit a patch to the kernel team knows that design changes are thoroughly vetted before being accepted into the source tree.

    Even I have completed some rather large projects without a producing a single bug. It wasn't a matter of coding skill, but rather, that I designed the software such that:

    • It was broken into modules with clean interfaces, so that each module could be independently tested and verified.
    • It was designed such that a bug in implementation would be apparent immediately (i.e. - it would crash).
    • It was designed to accommodate the inevitable change in requirements.

    Even very complex software can be written virtually bug free if good software engineering principles are followed. Something as simple as adhering to the Unix design principles [faqs.org] can drastically reduce the number of bugs in a shipping application.

    Generally speaking, the old adage about "failing to plan is planning to fail" holds true with software as well. The core idea behind software engineering is that quality is improved not by doing more testing, but rather by improving the process by which software is written. Consider the following two, widely used approaches to software:

    1. Define the requirements.
    2. Design the software as a large, monolithic application with numerous interdependencies and no clean interfaces.
    3. (RE)Write the software.
    4. Test for bugs.
    5. If bug found, goto step 3.
    6. Marketing promises something engineering can't deliver. Requirements change; goto step 1.
    7. Customer complains that feature X isn't implemented. Requirements change; goto step 1.
    8. Marketing adds features to product brochure. Requirements change; goto step 1.
    1. Define the requirements.
    2. Partition the requirements into easily tested modules separated by clean interfaces, anticipating the need to add future functionality at a later time.
    3. Design each module.
    4. Write the module(s).
    5. Test the module. Bug found? goto step 4.
    6. Marketing promises something engineering can't deliver. Requirements change; goto step 3.
    7. Customer complains that feature X isn't implemented. Requirements change; goto step 3.
    8. Marketing adds features to product brochure. Requirements change; goto step 3.

    With the second model, changing requirements do not require a complete rewrite or complicated analysis of the entire system. It is a flexible model. The key problems is that it is a hard sell - the design requirements phase takes more time, but it ultimately provides the flexibility that management and marketing require.

    One of these models addresses the fact that requirements frequently change; the other does not. One of these models takes into account the fact that complexity is hard for a single person to manage, and one does not. One model limits the amount of damage that a single, bad coder can inflict, and one does not.

    Yes, we may not fix every bug, but we can at least use sound design processes to minimize the impact of bugs. BTW, the fact that Source Gear can't interoperate with other databases is not merely a bug, but a design flaw. Had it been properly designed, using a

Slashdot Top Deals

If mathematically you end up with the wrong answer, try multiplying by the page number.

Close