Forgot your password?
typodupeerror
Bug Businesses Programming Software Technology

The Economics of Perfect Software 201

Posted by Soulskill
from the done-versus-done-ish dept.
An anonymous reader writes "This article takes the interesting perspective that leaving bugs in software is good — little ones, at least. This quote is particularly insightful: 'How do you know whether a bug is big or little? Think about who's going to hit it, and how mad they'll be when they do. If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug. It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way. If your program crashes on launch for a common setup, though, that's a big bug. Lots of people will hit it, and they will all be pissed. ... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about."
This discussion has been archived. No new comments can be posted.

The Economics of Perfect Software

Comments Filter:
  • How is this news? (Score:5, Insightful)

    by Dragoniz3r (992309) on Sunday March 28, 2010 @01:41PM (#31648618)
    Diminishing returns applies to programming too... big surprise...
    • Re:How is this news? (Score:4, Interesting)

      by Jurily (900488) <jurily@gm a i l.com> on Sunday March 28, 2010 @02:13PM (#31648918)

      Diminishing returns applies to programming too... big surprise...

      But you don't know how much each bug will cost. What if that little UI glitch gives remote root?

      BTW Joel Spolsky [joelonsoftware.com] said the same in 2001. Big fucking news indeed.

      • by siride (974284) on Sunday March 28, 2010 @02:42PM (#31649176)
        Then I would say that's a big bug, so it should be fixed.
        • by Jurily (900488)

          But how do you know before it's time to ship?

          • by Z00L00K (682162)

            Use tools like FindBugs [sourceforge.net] to root out as much as you can.

            Then you have at least shoveled away the bulk of stupid bugs that causes resource leaks and other things that makes a system go obnoxious after a while.

            Design bugs are a different kind of animal and those are harder to figure out since they aren't detected by the normal tools.

      • by Vellmont (569020) on Sunday March 28, 2010 @03:14PM (#31649442)


        What if that little UI glitch gives remote root?

        Then you're an idiot who didn't separate your software properly into layers and should learn, or get out.

        I understand your example, but the ultimate fear you're expressing about "the unknown" isn't warranted. Software is complex and can lead to unexpected problems. But worrying about every single minor bug possibly being a major one is just silly if you understand how the system interacts with itself. That's why good software is developed in layers. If you've really got a system where a UI glitch leads to a root exploit, time to throw away the whole application and start over.

        • by plopez (54068)

          Who cares about the UI giving an attacker root. As far as I am concerned it is a *minor* problem. I don't pay the cost, why should I care?

          For those of you who are a bit slow, I don't mean this. It just serves to illustrate a point.

        • What if that little UI glitch gives remote root?

          Then you're an idiot who didn't separate your software properly into layers and should learn, or get out.

          "You talkin' to me?" - Gates and/or Ballmer, or perhaps their legions of minions.

        • One of the best things I've read on this subject was an interview with top level muck muck at NASA (I think it was _the_ guy) when NASA was bent on fixing their safety culture, following a little bug that cascaded into millions of small pieces. In a safety audit they found a small number of broken wires in some electrical harnesses that weren't supposed to have this defect in this quantity. The engineers did what I might term a sensitivity analysis and determined that with all the other layers of redundan

          • Re: (Score:3, Interesting)

            by Vellmont (569020)


            The economic angle is a dangerous meme, because it lets incompetent management off the hook by allowing them to triage incompetence, and in particular, to ignore process failures, and the failure of team culture, both of which point back to management itself. We all know how well that worked out for NASA. This wasn't fixed until lives were lost.

            If you're writing code for NASA, or say the medical industry, I'd agree. But 99.9% of the developers out their are writing code that nobody is ever going to die bec

          • by azgard (461476)

            I agree. I was going to reply in the same manner, but probably not as good as yours, thanks.

            That's the problem with bugs. The small UI bug may be caused by underlining wrong state of the program, which may also cause crash or loss of data. So unless you know almost exactly the cause of the bug, you really don't know how serious it is (especially true for mysterious bugs - if a message overflows a message box, then you probably know the problem). If you know, on the other hand, it may be economical not to fi

    • Yeah, I remember waaaay back the saying was something like it takes 20% of the time to do the first 80% of the code, and 80% of the time to do the remaining 20%. It would be nice to get every last bug fixed but if you have plans for the rest of your life other than bug fixing you have to draw the line somewhere and get it released.
      • "Yeah, I remember waaaay back the saying was something like it takes 20% of the time to do the first 80% of the code, and 80% of the time to do the remaining 20%."

        Maybe it's because it comes from so way back you can't remember properly but it doesn't go that way.

        It goes "it takes 80% of the time to do the first 80% of the code, and 80% of the time to do the remaining 20%". There, fixed for you.

    • Re:How is this news? (Score:5, Interesting)

      by spongman (182339) on Sunday March 28, 2010 @03:52PM (#31649720)

      yeah, there's a also a mistaken suggestion that there's a correlation between the severity of the bug and the cost of fixing it.

      in general there isn't.

      you might have a crashing, data-destroying bug that's trivial to fix. or you might have a minor UI annoyance that would require a complete re-write in order to fix, possibly introducing a whole slew of new bugs.

      unless you have a deep understanding of the architecture of the application, there's absolutely no way to judge which class a given bug is in.

    • Sure, there are diminishing returns from the corporate payroll/sales perspective, but even tiny bugs tap manpower out of your customers, and as such, put a drain on the economy.

      Hours of my time every week are spent working around bugs that the OP would probably have considered too minor to be worth fixing. It's all nickel and dime stuff -- five or ten minutes here or there, sometimes even just seconds, but many times a day. We'd use less buggy software, but it doesn't exist. Sometimes we fix the bugs and

    • My question, though, would be how do you know which is which?

      And before I even start, a thing I learned pretty early is that if you aim low, you'll hit even lower. If you aim for a B or C in school, 'cause, well, no point in fretting over not being exactly perfect, you start getting D's and lower. I should know, I actually tried that philosophy for half a year or so, before realizing that lesson. Partially because life doesn't throw you exactly the curve you were expecting, and partially because once you st

      • by Vellmont (569020)

        How do you know? Experience. Experience reading through the code, and experience in software debugging.

        How do you know absolutely positively without a doubt? You don't, and you never will. All understanding and knowledge is a model of reality, and models are sometimes wrong. This idea people in this discussion seem to have that you can eventually, with just a little more effort make the system "perfect" is severely flawed. The disconnect the pragmatists in this discussion have with the perfectionists

  • by Anonymous Coward on Sunday March 28, 2010 @01:42PM (#31648626)

    You cant afford perfect software.

  • Oh Please (Score:5, Insightful)

    by WrongSizeGlass (838941) on Sunday March 28, 2010 @01:45PM (#31648660)
    The reason that every piece of software ships with bugs is because:
    * It's created by people
    * The programmers, testers, etc can never find all the bugs
    * It's gotta get out the door so you can pay your programmers, testers, etc
    * All of the above

    There is a matter of pride with individual programmers, small groups, and most open source programming projects. We'd all love to be able to crow about shipping a bug free project/product. We'd do it if we could ... and someday we will.
    • Re:Oh Please (Score:5, Insightful)

      by zappepcs (820751) on Sunday March 28, 2010 @01:54PM (#31648744) Journal

      Exactly. Most coders have to use the code they write. Leaving bugs is not something you do if you know they are there. Sure some people do that, but not the ones that want to get it right - at least for their own use. This is why some open source software is not infinitely usable - it did what the original author needed, and was not intended particularly to solve everyone's silly problems. The example of the 'A' key is probably something that was going to work soon, but the need for it never materialized and someone forgot to disable the code that checks for the letter 'A' - and since it was not implemented, nobody checked it.

      The first time I had code in production, running 24/7 I was kind of upset that I didn't need to look at it everyday, then amazed that it was working so well. Then, months later when I did have to go look at why it seemed to be not working right, I learned how important documentation and comments are. At this point I stopped being amazed that it worked well, but that it worked at all. Bugs are not left on purpose, only when there is not time or resources to fix them.

      • Re:Oh Please (Score:5, Insightful)

        by Jurily (900488) <jurily@gm a i l.com> on Sunday March 28, 2010 @02:33PM (#31649094)

        Leaving bugs is not something you do if you know they are there.

        Depends on how much of the code you have to refactor to get rid of it, how many users are annoyed at that particular bug in the previous release, and how many new users you'd get by implementing the most asked-for feature instead.

        You probably won't fix the bug where your text editor crashes if the user tries to open a file larger than 32 Gb first, if they've been also nagging you for global replace functionality.

        • by zappepcs (820751)

          You are describing the resources vs number and type of bugs. With enough resources, both problems would be addressed: if $file.size > 32Gb then err_msg and return. In this case, global replace is probably more work to fix. Still, it comes down to resources and the squeaky wheel syndrome.

          Lets not ignore or forget that in many commercial situations, the propensity for Marketing and Sales groups to describe the problems opposite of how I did. That is to say they will promise the hard fix before the easy one

      • Re: (Score:3, Insightful)

        by Vellmont (569020)


        Most coders have to use the code they write. Leaving bugs is not something you do if you know they are there. Sure some people do that, but not the ones that want to get it right

        This happens all the time. Have you never read release notes that have a list of "known bugs"? Generally that's open source software. The closed source software has the exact same list, it just exists on the software makers private network.

        Sure, if you KNOW how to fix the bug and it's easy most people will just fix it. The other

        • ...Have you never read release notes that have a list of "known bugs"? Generally that's open source software. The closed source software has the exact same list, it just exists on the software makers private network...

          This list also exists for aviation (and I'm sure other life critical) software. In the case of aviation software, it gets submitted to the FAA (or whoever your regulatory agency is, along with an analysis of each bug and why it is OK not to fix it.

    • by Lije Baley (88936)

      Duh, you just outlined the economic rationale. And b)We'd love to ship something bug free, but even as individuals with all of our time at our discretion we would not waste the rest of lives trying to get the bugs out of something as complex as modern software, so NO we won't do it SOMEDAY either. Maybe Skynet will though...

      • Re:Oh Please (Score:5, Insightful)

        by WrongSizeGlass (838941) on Sunday March 28, 2010 @02:11PM (#31648900)

        even as individuals with all of our time at our discretion we would not waste the rest of lives trying to get the bugs out of something as complex as modern software, so NO we won't do it SOMEDAY either.

        We may not ever accomplish it, but that doesn't mean we won't stop trying. Bugs slip through no matter how much we test. One reason is because no matter how we may try to break it we can never imagine the utterly creative stupidity that a user will cast upon our software.

        And as far as Skynet is concerned, it will be written by humans or by a system written by humans, so it's gonna have bugs, too (unless it was written by Deep Thought, but that's another story entirely).

        • Re: (Score:3, Insightful)

          One reason is because no matter how we may try to break it we can never imagine the utterly creative stupidity that a user will cast upon our software.

          That's one factor; but another larger factor is that there are often several orders of magnitude more users of your software than there are testers. Even if the testers were able to come up with all the "utterly creative stupidity" as the users, there wouldn't be enough hours in the day for them to test all those cases.

    • We'd do it if we could ... and someday we will.

      Really? How? I'm genuinely curious.

    • by ArundelCastle (1581543) on Sunday March 28, 2010 @02:47PM (#31649224)

      Even if it's bug free, that doesn't mean the software is designed to be easy or intuitive to use. There is often more money to be made from deliberate obfuscation. Every piece of Enterprise software I've used (particularly SAP) seems to follow this principle. And the huge aftermarket of expert consultants charging $150/hr for training and troubleshooting, seems to affirm it. Keep in mind those consultants are usually teaching the corporate experts, I'm not even touching the surface of end user training, which I'm experienced at being responsible for.

      The real money comes from support packages and direct-line support levels (ie: silver, gold, platinum and such to maintain a 24h call centre). Let's ask a simple hypothetical: what if Windows was bulletproof and bug free? How would Microsoft make any money? If nobody had reason to fix a problem within 30 minutes like their job depends on it? Or even not upgrade to the next version because the last one works better? With XP and Vista we already know the answer to that.

      • If Windows was truly perfect, then we could consider "Operating Systems" to be a solved problem. We wouldn't need a fifty billion dollar software company any more, we'd just need someone to print bits on a polycarbonate cylinder and/or transmit them over glass tubes.

    • Re: (Score:3, Funny)

      by Tablizer (95088)

      The reason that every piece of software ships with bugs is because:...It's created by people...

      I'm breeding cockroaches to write code. How ironic: bugs will solve bugs.
         

    • Re: (Score:3, Interesting)

      by scamper_22 (1073470)

      The other thing that might be a possibility... is that software needs to have bugs from the business end to ensure lucrative service contracts.

      Now this is just pure speculation of course... but I used to a work for networking vendor known for superior customer support... and making mega bugs in the servicing contracts as well.
      I sat there looking at some ridiculous policies in the software realm that almost seemed to encourage bugs in the code as opposed to writing good software.

      They were throwing code arou

    • by istartedi (132515)

      I would add, "* perfection can't be achieved within today's software lifecycle's".

      Maybe at some point in the future, the software lifecycle will be longer. A particularly mature piece of software might be considered "done" from the standpoint of features. Then, its lifecycle is indefinite. You might consider analog signal decoding as a very simple program with a feature set that is "done". In the early days of FM radio there was debate about the best circuit for decoding a signal, then they settled on a p

  • by Geoffrey.landis (926948) on Sunday March 28, 2010 @01:50PM (#31648698) Homepage

    Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug. And if you're not, that bug that you think will only happen in some situation that's vastly improbably will, in fact, actually hit at exactly the WORST possible time, because maybe that key sequence gets used in some extremely important operation that you hadn't realized your software was going to be used for. Or maybe that bug is ALSO triggered by some different sequence that you weren't quite prescient enough to realize would be common.

    • Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug

      That's just it. Keeping software in a controlled environment if there is any risk of it running amok is only prudent. In the enlightened days of Terminator Toyotas a cap on the damage caused by bugs needs to be considered.

    • by Bigjeff5 (1143585)

      It's not hard.

      Bug Report:

      "If I do X, Y, then Z, and sometime in the next 5 seconds do A, B,C, followed by ctrl-shift-A, I get an error message."

      If you've got a million customers, there are maybe 50 who are going to hit that sequence, and all it does is give them an error message without stopping their work in any way. The effect on the user is practically nill.

      Now, same bug, but for some reason you've buried significant functionality in this sequence that 10% of your users are going to want to use, it's mo

      • It's not hard.

        Bug Report:

        "If I do X, Y, then Z, and sometime in the next 5 seconds do A, B,C, followed by ctrl-shift-A, I get an error message."

        That's not the bug. That's a symptom of the bug. The bug itself will be something like a race condition, or a temporary variable that is not deleted after use. If it's triggered by sequence A,B, C-- and you don't actually what the bug is-- then why do you think know what else will trigger the bug?

        ...It's not a difficult process to figure out how much a bug affects your user

        Sure... if you can predict everything that your users are ever going to do with your software, now and in the future.

  • by pem (1013437) on Sunday March 28, 2010 @01:50PM (#31648700)

    If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.

    When I'm trying very hard to make a program do what I want it to, the more hoops I have to jump through for every iteration of trying to make it work, the madder I get. So, the fact that the software has dark corners that you can get to like this is already a major strike against it...

    • by hedwards (940851)
      You must be a Windows user or haven't updated to an Apple OS past the old world Macs. The only way of eliminating those dark corners is by eliminating them. Which coincidentally is the thing which angers people more than an obscure corner of the app having issues. I've largely given up on Windows except for a few things because there's somethings which you just can't do.

      And others like disabling WMP's stranglehold on my MP3 player requires a somewhat obscure incantation involving deregistering a dll file
      • by WrongSizeGlass (838941) on Sunday March 28, 2010 @02:20PM (#31648976)

        The only way of eliminating those dark corners is by eliminating them.

        And today's Yogi Berra award goes to hedwards. We'd like to thank everyone who participated for participating and the winner for winning.

      • by pem (1013437) on Sunday March 28, 2010 @02:42PM (#31649172)
        When I wrote:

        When I'm trying very hard to make a program do what I want it to, the more hoops I have to jump through for every iteration of trying to make it work, the madder I get.

        then you replied:

        You must be a Windows user or haven't updated to an Apple OS past the old world Macs.

        I have been racking my brain for the last half hour, trying to figure out what I wrote that bothered you so much that you felt compelled to resort to this sort of name-calling, but I can't figure it out, so expect a communication from my lawyer demanding compensation for this terrible libel you have committed about my computing practices in front of the entire slashdot community.

    • by Bigjeff5 (1143585)

      Not if it is some obscure functionality that hardly anybody is going to need. If you have a lot of features, that's the only way to do it.

      Sure, you could make your program do less, but why the hell would you want to do that?

      • by pem (1013437)

        Sure, you could make your program do less, but why the hell would you want to do that?

        Maybe because you believe in the Unix way of small programs to do a single thing well?

  • Dangerous approach (Score:5, Insightful)

    by mmmmbeer (107215) on Sunday March 28, 2010 @01:53PM (#31648730)

    This sounds a lot like the "Good Enough Software" policies that certain companies used to have. It's true that having a few minor bugs is acceptable; in fact, it's pretty much inevitable. But you should expect to have bugs that you haven't even noticed at the time you ship your software. If you start ignoring the bugs you do know about, you increase the total number considerably. From there, it's a slippery slope. Pretty soon, you'll be answering bug reports with a chorus of "Minor, leave it," and your code will be riddled with tons of minor bugs. Your users will go from "huh" to "what?" to "dammit" to "f*ck this!" Your software will look sloppy and unprofessional, and even if none of the bugs are showstoppers, your customers will be looking for alternatives.

  • Maybe. (Score:4, Insightful)

    by Junior J. Junior III (192702) on Sunday March 28, 2010 @01:54PM (#31648750) Homepage

    The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about.

    I think it also depends on how much it costs to remove the bugs. Often times, the small bugs that people are more likely to accept or tolerate are also very easy to fix. When the cost of fixing the bug is very low, it should be a no-brainer to do it. If on the other hand the bug is expensive to fix -- requiring a complete redesign and re-coding, then if the bug is not severe it may well be better to leave it in.

    • by Bigjeff5 (1143585)

      When the cost of fixing the bug is very low, it should be a no-brainer to do it.

      For large programs especially, but with any program really, there is a minimum cost to fix any bug. Most of them involve time, but there are other costs as well. Because of this, there are bugs that are small enough that never make sense fixing, unless you are already fixing a larger bug and fixing the small bug at the same time adds minimal extra cost. If there are no more large bugs to defray the cost of fixing the small bugs, it may never make sense to fix the small bugs if they are small enough.

  • by Palestrina (715471) * on Sunday March 28, 2010 @01:57PM (#31648772) Homepage

    Software is not so different from other engineering disciplines that we cannot learn from the best practices of adjacent fields. Although no human endeavor -- other than being Pope -- is infallible, we do see disciplined attempts to measure, manage and improve quality levels. The point is not to reduce the quality level to zero, but to know what your quality level is and be able to hit your mark. What level of quality is needed will depend on the market, your customers, the competition, the frequency of releases, whether the software is easily updated or burned into firmware and devices, etc.

    In the end, the best way to create higher quality software is not to find and fix more bugs. It is to use a disciplined approach to programming that introduces fewer bugs in the first place. If you focus on defect detection and removal, then you are fighting the wrong battle. You can't win doing it that way. Quality software comes from a disciplined process at all stages, from requirements to testing, and not just as an endgame activity to sway as many bugs as you can.

    • by Tablizer (95088)

      But the problem is that bug-severity level is generally subjective. Is a broken X worse than a broken Y? Without an objective metric, a "mechanical" way to measure quality is elusive.

      In the end, the best way to create higher quality software is not to find and fix more bugs. It is to use a disciplined approach to programming that introduces fewer bugs in the first place.

      The problem is that requirements tend to change too often. If you have a fixed target, it's easier to be anal about getting it right. Howev

  • ... a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble

    Is going to be one extremely unhappy user because they had a reason for going that deep into the sub-cellars of the software to get at that obscure feature ... and it is likely that they are the sport of user who is a bit more tech-savvy and ready to bitch than Joe Average user.

    • Unless they had no reason to hit the A button and it was an accident that just happened to trigger an error message without actually breaking any functionality.
      • Re: (Score:3, Insightful)

        by mikael_j (106439)

        How about we pretend that the user actually wants to use the feature to avoid analogies along the lines of "It's like saying a car is acceptably broken if the engine explodes when you turn on the radio since we can assume the driver had no intention of actually using the radio, that's just an obscure extra feature that no one uses..."...

        • by Bigjeff5 (1143585)

          It's more like there is a small beep on the radio when the users changes radio station while turning the ignition, but only if the park break is on. Very strange, and definitely a bug, but it affects an extremely small number of people and does not affect them in any significant way.

          If the engine blew up, that would be different, but it's just a beep on the radio - who cares?

          • It's actually more like the radio turns off in that situation, and can just be turned back on.
          • by mikael_j (106439)

            My example was based on the assumption that the error was somehow critical (as in, software/car refused to function due to the malfunction) and in that case any user who wanted to use the feature would've been pretty annoyed ("WHAT DO YOU MEAN I CAN'T USE THE RADIO WHILE THE ENGINE IS ON?! IT CAME WITH THE CAR! IT SHOULD WORK! WHAT'S THE POINT OF A CAR RADIO THAT ONLY WORKS WHEN THE ENGINE IS OFF?!").

            • Where as mine was based on the assumption that it was not, as in

              without actually breaking any functionality

              • by mikael_j (106439)

                Which was clearly not the premise of the post by Tsu Dho Nimh that you replied to.

                Talking about bugs that don't cause any problems wouldn't make any sense.

  • by Max Romantschuk (132276) <max@romantschuk.fi> on Sunday March 28, 2010 @02:11PM (#31648910) Homepage

    Sometimes it's better to ship a product and deliver it to 95% of the user base instead of having everyone wait because 5% wants feature X which is broken.

    But there is the option to disable feature X, so rather than knowingly ship with bugs you can often have the program show a notice that this feature is disabled or something like that.

    Generally when building software you'll have "Quickly", "Lots of features" and "Bug free". Depending on the software and project stage you'll want to strike a different balance. Releasing an alpha which has lots of features quickly with loads of bugs is OK. Releasing a final release of a program handling financial transactions with loads of bugs is never OK.

    But yes, it's a question of economics, and what makes sense for a given project at a given time.

  • by Eponymous Coward (6097) on Sunday March 28, 2010 @02:16PM (#31648946)

    It isn't always easy to judge the severity of bugs. Exploits often grow from a black hat figuring out how to crash a program. Some of the greatest exploits started with the smallest of footholds.

  • by Vellmont (569020)

    Isn't this how people ACTUALLY write software already? Resources aren't infinite, and unless you're NASA writing code for the space shuttle, all bugs don't have to be fixed. I learned about triage and fixing the "big bugs" 15 years ago in school and it was certainly common practice in the industry then.

    I was going to say "what a stupid article, everyone already knows this". But judging from the responses I guess everyone doesn't.

  • > If a user who goes through three levels of menus, opens an advanced
    > configuration window, checks three checkboxes, and hits the 'A' key
    > gets a weird error message for his trouble, that's a little bug.

    That's a symptom, not a bug. It could be a symptom of a buffer overflow that, if not fixed, will soon be exploited to clean out the bank accounts of 100,000 of your customers. You won't know until you've fixed it.

  • mediocrity (Score:5, Insightful)

    by electrogeist (1345919) on Sunday March 28, 2010 @02:40PM (#31649162)
    "Once genius is submerged by bureaucracy, a nation is doomed to mediocrity. " -Richard Nixon

    s/nation/project/
  • Yeah, in my own mind I inserted that extra word in the title, and I was disappointed that it wasn't about that at all. I'd like to see an article about that, describing how the "perfect" game would be an economic Bad Idea, and including interviews with game developers who finally admit that they deliberately repeat old shortcomings and mistakes and stop short of perfection, knowing that the perfect game would completely destroy the market for next year's game. I can think of one or two that actually tried

  • If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.

    1. If that error message refers to "H-Tilt", then that's a big bug no matter how many levels of menus you go through.

    2. If a user can provide a reliably reproducible test case like that for the bug, then it's one you should have caught in testing.

  • Is this still Slashdot? Why has nobody made the obvious quote from Fight Club yet?

    I haven't even seen a numbered list ending in "Profit!" Why are you all letting me down?

  • I used to work for a small computer firm in Weybridge, England. Oh, damn it, since it collapsed ten years ago, I may as well name it: MTA (Computer Consultants) Ltd. We had a project between 1997-9 to write a software demonstrator for a radar resource manager for the Eurofighter project, for DERA Malvern. The project was divided into two parts, of which phase 1 went through a successful factory acceptance task. However, a few bugs had been found in the programme after this, one of them, due to me, was fairl
  • by Garrett Fox (970174) on Sunday March 28, 2010 @03:22PM (#31649500) Homepage
    The post talks about minor bugs being the ones that are hard to reach, but that's not necessarily the case. There was a piece of radiation-beam hardware used for cancer treatment (the Therac-25 [wikipedia.org]), that became a case study in engineering because of a literally fatal flaw. It was possible to mis-configure the machine so that it struck the patient with a much more powerful radiation beam than was normally allowed. The relevant point was, this situation only happened if the operator did some obscure, seemingly unlikely combination of actions that would result in a lead plate getting misaligned or something. Yet it happened at least six times, killing at least two people. The fact that the bug was caused by this particular sequence of actions made it that much harder to identify -- and it was not a minor bug worth ignoring.
    • by plopez (54068)

      Exactly. What, BTW is a "minor bug"? How do we decide this if we haven't experience it? If no one has seen it yet, how do we judge?

        Also, the Ford Motor Company in the early 70's made an informed, rational and very wrong economic decision to produce the Pinto despite knowing it could be dangerous. They measured things out and decided the danger was worth it in terms of profitability.

      This argument is just an excuse for not caring.

  • If I connect my TV remote to the mains AC, it will break. I blame the makers for not 'validating' my input voltage. My Cups/Mugs all have bugs, as when I drop them, they break....silly makers for not designing in dampers to cushion the blow. My car has bugs.... I can very easily crash it, how dare the manufacturers make something I can crash by just pressing the buttons/ turning the wheel in the wrong order.

    My point is, that practically everything will fail, or demonstrate unpredictable behavior if it is s

  • Perfect software is like a perfect person: hard to find. Even if you did find it, then it probably wouldn't be doing things in the way you want it to.

    If I am asked to add a set a features and make it perfect, then I will do the best job I can, but in the end the question to be asked is "do you want perfect software or a deliverable?". Perfect software is also like a derivative, in that you can always get closer to your integer the more you work at it, but still not be there, it simply tends to infinity.

  • If you don't have pride in your work, quit. Making excuses for bugs has no excuse. It guarantees you will ship bad software. There is a ratcheting effect. At first you accept some defects, then you accept more, etc.

    And if I was that user I would be angry. I just wasted all that time navigating through all of those menus (also a sign of bad software, too many levels) for no good reason. You just pushed off your lack of caring on to me. I would look for better software. Something which costs me less $$$$ in l

  • The little bugs add up, and users consider your software and even computers in general to be very unreliable these days. The PC has such a bad reputation that users just openly mock it all the time. It's expected to suck. Microsoft software especially is expected to have bugs. The whole platform is just a big bugfest, a race to the bottom in quality.

    Part of why Apple has been making hay over the past decade is that their software is just more reliable than what people have come to expect. They spent years p

  • When I first started programming they liked to compare programming to building a house. I had to point out that its not like building a house. With programming you can start from the top and go down and you can start at the bottom and go up and you can start at the east, west, north and south too. You can build the parts in any order.

    However there is an aspect of programming which is akin to house building and this is the idea of the framing carpenters and the finishing carpenters.

    Who here wants to use a

    • It is much cheaper to write software to do the job right the first time. This makes later debugging much easier to do because the rest of the system can be trusted.

      So here is a story on one of my programmers. The company was under tight deadlines. That was their own damn fault because the previous 6 consultants couldn't figure out how to write a single line of code on their watch. Of course they didn't tell us when they hired us! Go figure?

      I told my project team: Check every error code - without excep

  • Where I am, bugs, half-baked functions and missing features allow expensive software contracts to keep development teams alive. As soon as software become stable, customers tend to start killing off support contracts. Well, a little pain, is good for the soul. In this case, the user's pain, for the developers' soul.
  • After all, they're both mythical beasts.

  • I had a software package to which I was adding features and there was one nagging, subtle bug that kept me chasing my tail for a couple of weeks.

    I was fairly junior in my career, so you can imagine how I felt when the VP of Software Development called me in for a chat. He impressed on me how it's really not practical to hold up a product shipment for some "little bug". There will always be "little bugs", and I needed to get over it and move along.

    I accepted this sage advice (and counted myself lucky that

The universe is like a safe to which there is a combination -- but the combination is locked up in the safe. -- Peter DeVries

Working...