Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
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

Comments Filter:
  • by exp(pi*sqrt(163)) (613870) on Thursday May 25, 2006 @11:00AM (#15402263) Journal
    Theoretically, there is no language that is more or less prone to bugs than any other language as understood in Turing Completeness
    Frankly, this is complete garbage. Try writing an application in the Turing complete language Brainfuck [muppetlabs.com] or 6502 assembler and compare that with writing in the Turing complete language Haskell. Turing completeness is completely irrelevant and you're simply quoting CS 101 to give your comments an air of authority.
  • 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...

  • Re:bugs, so what? (Score:3, Informative)

    by Al Dimond (792444) on Thursday May 25, 2006 @11:23AM (#15402526) Journal
    The Computer Modern fonts (as used in TeX) are perfect! Or, at least, perfect enough that "These fonts are never going to change again" [stanford.edu]. 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.

  • Re:My experience (Score:2, Informative)

    by subnomine (849148) on Thursday May 25, 2006 @12:56PM (#15403392)
    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! :)
  • Turing machines (Score:3, Informative)

    by DragonWriter (970822) on Thursday May 25, 2006 @04:16PM (#15405205)
    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.)

  • by Anonymous Coward on Thursday May 25, 2006 @04:36PM (#15405385)
    The closer to the machine a language makes you work, the harder it is to keep higher level details in the back of your head.
    This may be true, but Brook's Mythical Man-Month [wikipedia.org] explains the same phenomena differently, stating that all languages produce an equivalent number of bugs per 1k lines of code.

    I realize the book is ancient (1975!), but it corresponds to my experience. Perhaps extremely cryptic languages (such as APL) are an exception.

Utility is when you have one telephone, luxury is when you have two, opulence is when you have three -- and paradise is when you have none. -- Doug Larson

Working...