Slashdot Mirror
Why Buggy Software Gets Shipped
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."
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
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 Computer Modern fonts (as used in TeX) are perfect! Or, at least, perfect enough that "These fonts are never going to change again". I think the same thing is also true of TeX itself, but I may be wrong. :-P
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 the airline industry worked a little but differently) so the relationship was a little closer than the typical developer/user relationship for shrinkwrapped software.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I would agree on all points, and add one more group of causes for bugs: morons and crack-heads. Ok, maybe that's obvious...but not to management. I worked for a company whose tiger-team of contract labor consisted of: a drug abuser, a dead beat dad, an imbecile, and one really nice guy of no special education. Of the four, the crack-head hoodwinked management into thinking he was crack-coder, a virtuoso. He used 8 lines of code to copy a (double) into a (long) using sscanf() (instead of just using the cast). No, I'm not one of the four, nor management! :)
The theoretical limitations of Turing machines might affect the ability to detect bugs (then again, the halting problem -- one of the most common "limitations" referred to and the one brought up repeatedly in this thread -- is only intractable for a universal Turing machine; for real machines with finite memory, which, unfortunately, real comptuers tend to be, halting is decidable, so that particular limitation is no excuse for software bugs on real machines), but the practical difficulty of establishing correctness are substantial, though.
And those practical difficulties are, as I understand things, affected significantly by language features, which is why some languages (like Oz) are designed with ease of reasoning about code as a priority.
(And, of course, a major practical limitation of proving correctness is that proving code is correct doesn't help if the environment it runs on isn't also proven.)
I realize the book is ancient (1975!), but it corresponds to my experience. Perhaps extremely cryptic languages (such as APL) are an exception.