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.
And do we really need that much whitespace on a news page? I know about that whole '10 words per line' usability mantra, but it looks fucking ridiculous. Why can't all the other website owners just think exactly like me?
Wow, look at all that rebuking. Do I win Slashdot?
(IAJAFSS (I Am Just Another Fucking Smartass Student))
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.
I propose we call a meeting with Groups 3-12 and 15-20 and see if we can get some kind of real analysis of what Groups 1 and 2 are really thinking.
..why buggy $oftware is $hipped. Can anyone help me with thi$?
In many cases, the customer *needs* the software now, bugs be damned. If you don't, your company goes under.
Help kill corporate productivity!
> If you are in group two, than I post this for you.
> Theoretically, there is no language that is more or less prone to bugs than any > other language as understood in Turing Completeness. Without delving too much
> into this, it simply states that all languages emulate a Turing machine to some
> degree and therefore should be capable of everything a Turing machine is capable
> of (although I don't think this says anything about time/space efficiency).
If you understood Turing Completeness you'd be in group one.
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.
Managers.
Specifically, managers who don't know enough about the project (whatever it may be) and make unreasonable promises to their superiors about shipping dates. It seems that the way most businesses are set up reward managers who complete projects on time or early, rather than the quality of the product. As a result, managers tend to rush development teams through their tasks and the end result is a buggy release. And a manager with a bonus check.
If software shops could change their focus to creating a better release product but with a flexible time schedule...say for instance, rewarding managers for fewer bug reports and service calls rather than completion dates, you'd have an entirely different picture.
Weaselmancer
rediculous.
compiler error: $DIETY does not exist (except in weight-loss applications). Please use $DEITY.
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.
We buy buggy cars, houses, and anything else you can think. Nothing with the aim of perfection *ever* gets done.
So what's the big deal?
I understand shipping something like bad tires that will eventually kill people should not be done, but anything that does not cause harm or major finantial distress should just be dealt with during the normal lifetime of a product.
I am an embedded systems developer. We take care of the functionality problems before shipping and work on the corner cases as we move along.
There is no way a group of people, doesn't matter how large, can think on every possible problem that can occur.
Show me one thing that's man made and that's perfect and I will eat my shoes.
-later!
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.
How very black and white of you. So the large Investment Bank shouldn't ever put its new trading system in place, which has the potential to make them hundreds of millions of dollars, because of a couple of small, esoteric display bugs in the GUI?
The real world is all about risk/benefit analysis. The only places that ship guaranteed bug-free code are those where human life is directly affected by the output of that code. For anything other than trivially simple systems the cost/benefit analysis will rule out formal code proof in anything but the most necessary of circumstances.
The gift of death metal does not smile on the good looking.
Type in a sentence you're thinking about. Highlight part of it and bold it. Highlight a different part and hit escape seven times.
ON, I did that. Where's my damn easter egg?
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.
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.
You bastard! When I typed this, my PC froze! But since it's also a server, it rebooted itself, mailed a Nigerian scammer my home address, started a DDOS on the local authorities and blew itself up, taking half of the data center along with it. When I came home, the Nigerian scammer had raped the dog and the cable guy from the ADSL company who had showed up at my house. When I told my wife, she replied that she didn't care since the left me this morning and took the house along.
So thanks to your FUCKING easter egg, I am divorced, broken, homeless and worst of all, WITHOUT AN INTERNET CONNECTION.
Thanks for nothing.
8 of 13 people found this answer helpful. Did you?
Group 3 consists of people who acknowledge that fixing all bugs is impossible, and that judgement is necessary in deciding which bugs need to be fixed... but nevertheless contend that within the personal computer software culture in the United States, these judgements consistently err in the direction of shipping software with too many bugs.
The personal computer software culture in the United States is much like that of automakers in the United States circa the sixties, who insisted that the low quality of U. S. autos was the result of the best and wisest judgement... and that public toleration of low quality, as reflected in good sales and profits, validated their judgement.
Good sales and high profits, that is, until overseas competitors began to ship high-quality cars to the U. S.
"How to Do Nothing," kids activities, back in print!
Read: we got embraced and extended all to hell. What do to? Blame SQL! That's right, the language itself! It "isn't portable". Also blame users! "People who refuse to use SQL Server can't use Vault."
And here's some typical MS morality for you: "I'd probably even patent this algorithm even though, in principle, I believe software patents are fundamentally evil."
I don't expect bug-free software of any real complexity to be shipped often. But the examples are both interoperability problems, and not actual bugs. Looks like an excuse to marginalize the non-windows crowd. "...only affects users on non-Windows platforms, a rather small percentage of our user base."
My turnips listen for the soft cry of your love
It took a leaked Microsoft memo to find out Windows 2000 shipped with 65,000 bugs. Even the author of the memo wrote, ""How many of you would spend $500 on a piece of software with over 63,000 potential known defects?"
The problem is with a number that large, no matter how small the proportion is to code size, the backlash would be huge. No potential customer could hear that number and then actually want to buy a copy. I believe they should disclose as much information as possible. But from their perspective no amount of marketing could make up for the negative impact of disclosure.
Developers: We can use your help.
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.
Did anyone see the MTV special about the new XBox 360 game Gears of War? At the end of it, Bill Gates walks up to the Lead Developer (atleast i believe he was the lead), and basically says "So, you are gonna have this ready by August, Right?"... The developer reluctantly agrees that it will be ready by August. Bill Gates responds "Great, we are counting on you." Talk about pressure to get a product out. Can you say buggy release?
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.
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
One thing which immediately struck me was that the author seems unaware of a key software engineering principle: Reducing design complexity reduces the number and severity of bugs. By now, we all know that there are tradeoffs between complexity, time, and features. However, all other things being equal, some people and organizations consistently produce better software than others. Consider, for example, Linux and Windows. The key reason Linux is more stable and more reliable than Windows is that the process which produced Linux is inherently better at catching and correcting flaws than the one used to produce Windows. Anyone who has ever had to commit a patch to the kernel team knows that design changes are thoroughly vetted before being accepted into the source tree.
Even I have completed some rather large projects without a producing a single bug. It wasn't a matter of coding skill, but rather, that I designed the software such that:
Even very complex software can be written virtually bug free if good software engineering principles are followed. Something as simple as adhering to the Unix design principles can drastically reduce the number of bugs in a shipping application.
Generally speaking, the old adage about "failing to plan is planning to fail" holds true with software as well. The core idea behind software engineering is that quality is improved not by doing more testing, but rather by improving the process by which software is written. Consider the following two, widely used approaches to software:
With the second model, changing requirements do not require a complete rewrite or complicated analysis of the entire system. It is a flexible model. The key problems is that it is a hard sell - the design requirements phase takes more time, but it ultimately provides the flexibility that management and marketing require.
One of these models addresses the fact that requirements frequently change; the other does not. One of these models takes into account the fact that complexity is hard for a single person to manage, and one does not. One model limits the amount of damage that a single, bad coder can inflict, and one does not.
Yes, we may not fix every bug, but we can at least use sound design processes to minimize the impact of bugs. BTW, the fact that Source Gear can't interoperate with other databases is not merely a bug, but a design flaw. Had it been properly designed, using a
The society for a thought-free internet welcomes you.
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.
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 share your vision of hope for the future. But I would first like to digress for a moment on your statement before fleshing out how I DO agree with you, too. (BTW it is currently 4 AM so I apologize if this rambles a bit. I've tried to go back and edit it to make it clearer, but I seem to keep making mistakes. That in itself seems apropos to this discussion. <grin>)
In my experience, it's more like: the customers get what they asked for and then find out they did NOT get what they WANTED. The problem is that the customers do not understand software, the environment the software runs in (hardware, political, and legal), what is possible, and what has never been done before. It's more often the case that "they will know it when they see it, but they can't really tell you what THAT is, exactly, before hand." Further, because they do not know what is and is not possible, they don't understand the ramifications of their choices. Lastly, there is a HUGE difference between research and development. It's one thing to code a one-off of something you've done many times before; it's quite another to do something completely new, and get it right the first time. As more and more people become computer literate, and gain first-hand experience on using software, I am cautiously optimistic that this disconnect will diminish over time.
Helmets - As an example, I remember watching some old footage and was amazed to see that professional hockey players did not wear helmets. Now it sure likes ALL players wear them. Why? We learned the added inconveniece and expense was worth it. I've worked on development projects where there was no allowance (i.e. time and money) set aside for anything but the barest amount of testing. Now I am increasingly seeing that built into development schedules, as a matter of course. Granted, in some cases this testing would be analagous to a hockey player wearing only a LEATHER helmet (instead of today's high-impact plastic) but it shows progress and gives me hope for the future. I welcome the day when testing and quality assurance are an integral part of EVERY development effort instead of a rare luxury. The benefit is that libraries of well-documented and thoroughly-tested code will become increasingly available. AND the methodology to USE them PROPERLY, (i.e. SAFELY!)
It's thanks to developers' incessant optimism, I believe, that we have our current problems, and also the seeds for the solution. Please, don't get me wrong on this one. IIRC, it was Tesla who said that "If I had known it was impossible, I wouldn't have done it." We create doftware to do things which have NEVER been done before, ever. Even in the face of statements like: "That'll NEVER work!". The response? "Oh yeah? Hmmmmm. Wait a minute! If I, hmmm, and then... AHA! I think that just might work!" And on nothing more than a hunch, a hope, and a blind ignorance of just how many hours of debugging it will entail, we regularly go off and do something absolutely incredible. I have gained much inspiration from a quote by Mark Twain:
In tandem with this one by Thomas A. Edison:
It's that thrill which drives so much inspiration and pers