use Perl

• Failure is an option (Score:2)

  by Matts (1087)

  That's the problem with software - failure really is an option. It's not like we're building bridges or hospitals.
  
  Case in point - today we discovered a bug in my spam scanning software that has been there for years. Hundreds of thousands of mails have triggered this bug. Yet we only just noticed it because failure wasn't a total showstopper. Creating the software with a tool like Alloy would have caught the bug (probably) but it would have also taken a hell of a lot longer to get the software written.
  • Re:Failure is an option (Score:2)

    by Ovid (2709)

    Depending upon what you're doing, failure may not be an option. Consider the Therac-25 [wikipedia.org], a well-known radiation therapy machine which killed at least 5 patients due to a software bug.

    Or how about the doctors who were indicted for murder [baselinemag.com] because they didn't double-check the results of some software and had several patients die as a result?

    On a less lethal scale, tests can be used to prevent software flaws from reappearing, but if the underlying design of the software is flawed, the fixes that go in place
    • Re:Failure is an option (Score:2)

      by ziggy (25)

      Consider the Therac-25, a well-known radiation therapy machine which killed at least 5 patients due to a software bug.

      The Therac 25 is a really important story, but it is an outlier, and ultimately not relevant to most discussions about bugs, reliability or catastrophic failure. There is no general lesson to learn from that, except to be extremely careful when working on a system where life is on the line (medical, embedded or otherwise).

      Case in point: I've worked on many online publishing systems
      • Re:Failure is an option (Score:1)

        by mock (38) <reversethis-{moc.tsewcesnac} {ta} {kcom}> on 2006.06.02 3:42 (#47981) Homepage

        No, this is the worst case scenario: vulnerabilites in SAP [cansecwest.com] or perhaps this Who turned out the lights [cansecwest.com]. The price of catastrophic failure really can be that bad. The problem is, that the same components that you used in your publishing house, or to bend sheet metal are being used everywhere else as well - And they suck!
        
        Now for my lovely little anecdote to debunk the rest of your point. Back before I worked for ActiveState, I was an IT consultant to a very large forestry company (who shall remain nameless). Someone didn't configure the access controls on the gis data server correctly. Someone accidentally uploaded the wrong data to that server. Several thousand acres of protected national park old growth forest accidentally got clearcut. But that isn't the funny part. The funny part is that the company paid the several million dollars in fines without even blinking, because it happens all the time. It was even profitable, but the net result is a lot less parkland for you and I to enjoy because of a measuring error.
        
        Bugs matter.

        Reply to This

        Parent

        • Re:Failure is an option (Score:2)

          by ziggy (25)

          mock! How've you been? Where have you been hiding yourself?

          Bugs matter.

          Yes, they do, but not all bugs have equal weight. Not even security related bugs. Do I care if a package has a known buffer overflow if it's running inside my firewall? OK, I care, but do I care as much as I would if it's in the DMZ or on a public site? Do I care enough to patch inside the firewall first, leaving a public machine wide open?

          We can trade annecdotes all day about how bugs matter or don't. In the end, thou
          • Re:Failure is an option (Score:1)

            by mock (38)

            Well I'm still kicking around Vancouver, however you might see me in London or Tokyo as well. I founded MailChannels [mailchannels.com] with another former ActiveStater, and I've been making the bits go for CanSecWest [cansecwest.com] and associated conferences for the last few years. Right now, I'm reworking our conference registration system, which entailed an audit of all the bits I was planning on using. I'm not really pleased with what I found.
            
            While I don't disagree that perspective is necessary, obviously when limited resources are