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."
Anyway, I do agree with the author for the most part (its all pretty 101 risk assessment stuff). It is inevitable that software will have bugs in it (especially commercial software shipped to a schedule). This is not really news tho'.
What I would like to see is some vendor honesty. How about making a list of known bugs available to your customer prior to purchase? (I know, I know, fairly warning a customer is madness, etc etc).
There are shills on slashdot. Apparently, I'm one of them.
The argument about the enormous bug count in Windows isn't really about every last bug being fixed. The article fails to address a separate question: whether you're allowing the public to do your beta testing for you.
The idea of QC/testing/beta/whatever the heck you want to call it is that you get as many bugs as you can fix while accepting the ones that will remain behind. That's absolutely correct. However, there are companies - like Microsoft - that are notorious for either being sloppy and not getting bugs they should have, or just straight up not caring at all and rushing a product to market that legitimately shouldn't be there.
The argument can even be extended to good coding practices, like worrying about security fron start to finish rather than after you've entered beta (another well known Microsoft flaw, though they're getting better at it). That reduces the number of bugs to begin with, which in turn gives a better product.
ACs are modded -6. I don't read you, I don't mod you, I don't see you. Don't like it? Don't be a coward.
..why buggy $oftware is $hipped. Can anyone help me with thi$?
99% of the time it's because upper managment either promised the customers features that could not be implemented or gave the programmers too little time and/or resources to finish the job. While not software development, I am having to deal with a similar problem right now. We are moving our website to a new CMS system. So we have to move all of the content from our old pages to the new system using a slow, buggy, web based system. In the beginning we were told by IT that we had until June 5 to complete the move, so we scheduled our time accordingly. Things progressed slowly but in time to meet the deadline. Then Tuesday morning we get a call from the assholes in PR that we have to have everything done by this Friday. We just had our remaining time cut in less than half. There is no way we can get done, so the site will be incomplete. PR gets no blame and we look bad.
Regardless of the nature of the software development team, the nature of competition remains the same.
Stagnation is costly - delaying a product launch drives people to the alternatives (both due to the alternatives updating faster, and due to the lack of progress seen by the outside world).
Of course, buggy software is costly in terms of reputation, as well, so the end question becomes at what point will the delaying of the release cost us more market share then the remaining bugs will.
Unfortunate from a purists eyes, but it's just the way things go.
Because, by and large, no one gets killed when commercial software crashes.
In those cases where it does; e.g. medical/aviation software, usually embedded people take the time. If aviation software designers cut the same corners (w.r.t. bugs vs. features) that office software designers do, planes would fall out of the air and people would die. So they write well engineered software, in well engineered, fault tolerant languages (lika Ada). (Yes, yes, Ariane, but thats the exception that proves the rule)
The real reason buggy software is shipped, is because buggy software is accepted by the market, and people will keep buying it, and continue to roll their eyes when it crashes, because they're completely inured to it, and many of them have reached the conclusion that its literally impossible to write robust, stable software.
It's not, but the profit margins are narrow, and no-one seems to mind (or rather they mind, but keep forking over their money anyway). So no-one bothers to.
Face if folks, we're enablers.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
The article was about why known bugs ("thousands of bugs") aren't fixed before ship, not why all bugs aren't found.
With great power comes great fan noise.
Look at Vista. Everyone is complaining about it not shipping on time. I have yet to hear anyone say. It is a good thing that Microsoft is fixing all those bugs.
Product ships late because of bug fixes. Why is it taking so long.
Product ships on time with bugs. Why didn't you fix the bugs before shipping.
You just can't win
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
And if our IT staff had the same intelligence, competence, and vision as our management team, we'd kill over 10,000 people a week.
The Independent: Reverend Spooner Arrested in Friar Tuck Incident - ISIHAC, Historical Headlines
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Now, as to why bugs don't get quashed quickly:
I see each of these every day!
Logic is the beginning of reason, not the end of it.
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...
That's foolish. There are bugs in every project of every size. Including bridges. And skyscrapers. Remember the Tacoma Narrows Bridge?
Normally, those bugs have low Severity or Frequency (or both). Sometimes they have catastrophic severity.
Did you know that the twin towers were built to withstand a direct impact from a 707?
Bugs are a fact of life. They follow from the mantra 'nothing is perfect.'
I currently have no clever signature witicism to add here.
No dude, you're wrong. I suppose you can believe that with sufficient abstraction, you're right, but you're not. All that formal systems theory and Turing business is great talking about abstract systems running abstract algorithms, but such discussions have zero to say about anything having to do with HUMAN error, which is what we're talking about here.
I've probably spent about equal time writing C and writing in higher level languages, and I can promise that I make fewer errors in higher level languages, doing equal tasks. I think anyone with a lot of code under their belts can make similar statements. 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. In a high-level language, you're much less likely to make a low-level error (and any you make will almost certainly be caught by a warnings mode on the compiler, and this leaves you to keep more of your neurons working on, for instance, keeping your database and its wrapper classes working together correctly -- a task that is, perhaps, a simple afternoon's work in Python, Perl, Ruby etc. two days in C# or Java, and a week of hair-pulling in C... and well... I doubt such a thing has ever been done in assembler.
Anyway, drop the semantic B.S. this is a debate about practicalities.
In Capitalist America, bank robs you!
Why do you dismiss a complaint which speaks to the very heart of the problem? A large class of bugs simply would not exist were a different language used. This is not pie in the sky stuff; it's a real phenomenon.
If one language is less error-prone than another, then an application written in that language will have less bugs.
If an error-prone language is being used to write software, then this surely has to be a reason why buggy software gets shipped. Why are you dismissing people who complain about error-prone languages?
Be true and faithful like your dog; but don't eat vomit like your dog
Think of it this way:
At least that Nigerian scammer doesn't have your address anymore...
This rating is Unfair ( ) ( ) Fair (*) Funny
Sigh... If only. Modding would be so much more fun.