NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Failure is an option (Score:2)
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)
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)
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)
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
Re:Failure is an option (Score:2)
mock! How've you been? Where have you been hiding yourself?
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, though, the severity of a bug or a catastrophic failure is directly related to the amount of damage it could do when something breaks. The forestry example isn't of the same scale, because it has a lasting impact; customers losing access to information they've subscribed to is regrettable, should be prevented with all reasonable effort, but nothing to lose sleep over. (Setting loose millions of credit card or medical records on the other hand, well, that's pretty damn serious.)
In construction, waste happens and you need to factor that into the overall cost. It's annoying when that waste is expensive and needless, but it's certainly not catastrophic in any real sense, not when you should really be worrying about panes of glass falling and decapitating some innocent bystander.
Bugs matter, but so does perspective.
Reply to This
Parent
Re:Failure is an option (Score:1)
While I don't disagree that perspective is necessary, obviously when limited resources are