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.
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). One language may be better supported than another or have more libraries but we are going to assume these issues to be irrelevent to our discussion on applications--let us look as all applications being written in the same low level language that your computer directly understands. I don't want to compare architectures either, let us assume they are equivalently prone to bugs and are basic Turing machines.
If we think about a binary executable program (machine language consisting of ones & zeros) then we must recognize that the program's memory space has many many states. Open up your favorite word editor. Type in a sentence you're thinking about. Highlight part of it and bold it. Highlight a different part and hit escape seven times. Do you think that this scenario was tested?
My point is that it is an impossible herculean task for the developers to test any application in every state. They can come close and smart software design can leave an easier job for the testers but it will never be completely tested.
I would define the term bug as "undesired behavior" and I suggest they be thought of in this manner. I will also make the statement that no piece of software can be garunteed to be free of undesired behavior due primarily to the above analysis of them being amazingly complex machines with a large state space. To take a stab at it mathematically, this browser (Firefox) is operating with a 48,604 Kb memory footprint (I have many tabs open). That's 49770496 bytes or 398163968 bits. Each bit can be on or off meaning that for the amount of memory my browser occupies now, there are 2^398163968 different possible states for any similar sized application running. Now, to add even more complexity, that state space adjusts according to what the application requires for memory.
As our applications become more bloated, the situation only worsens. That is why development phases are either getting longer or requiring larger teams from the beginning of the project (mythical man month noted). At what point does the testing phase end? Hopefully never. Hopefully your software that you acquire is supported until the end of time
If you're wondering how companies can ship software with bugs, you should be wondering how is it possible not to ship software with bugs. You should also understand that there are rigorous standards and practices implemented along the way to prevent the most devestating bugs from escaping. If the company making the software has a history of failing in extinguishing the most glaring of errors, simply stop purchasing their software or demand the support you need.
My work here is dung.
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))
This is one of the reasons I truly despise the economics of commercial software ... ugh ... every word of the post is correct. $DIETY, I hate commercial software....
FP?
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.
Long answer: Our code base is so insanely intricate and unmanaged that we can't implement a simple bug fix without inducing an enormous number of regressions.
Article summary : We're incompetent, but no more so than everybody else.
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.
Marketing! Marketing! Marketing!
fak3r.com
..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!
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.
Careless mistakes and security holes? What about MS taking 200+ days to patch a critical security hole? What about bugs/security holes due to bad management styles/lazy programming or a combination of the two?
Sure, bugs / security things will happen... but how many are too many? And when is an acceptable time frame to fix those, and fix those that pose major security risks?
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.
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.
His little 'graph the severity against the frequency', but 'never' make easy changes just because they are easy plan fails when it comes to typographical errors. They may not show often, and are certainly not severe, but they ARE extremely easy to fix, and have no further impact (ie: fixing a typo will never cause more bugs). But, according to his rules, he'll never fix a typo.
"It is better to ship a product with a known quality level than to ship a product full of surprises."
And it's BEST to get all the bug out first!
There are products available, memprof, Coverity nessus which can be used to find and fix common forms of previous bugs. These fix everything from repeating previous security flaws (I note a previously unknown DoS flaw I found in Asterisk's skinny codec ages ago which emulated a bug in cisco call manager exactly, which I found with Nessus), to bad programming, or programming mistakes (Coverity), to memory leaks (memprof). These types of bugs are unacceptable, there are tools out there to detect them DURING THE PRODUCT DEVELOPMENT CYCLE. I am not saying that you can fix every bug every time, but 5 digit numbers of open bug reports are unacceptable.
Software will stop being buggy as soon as people stop putting up with it.
If people actually stopped buying Windows because it sucks, you can bet your sweet darned bippie Microsoft would stop making it suck. As it is, honestly, why should they care? People keep using Windows. It makes no business sense for them to focus on quality if quality doesn't sell.
<flamebait>There is already a company that caters to the niche market that actually gives a rat's ass about consumer software quality. It's Apple -- and oh, look at how they just dominate the desktop computer market....</flamebait>
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!
...Eric Sink, has a interesting piece on his blog about open sourcing Java. He says he's a C# programmer now, so kind of a different perspective...
The Army reading list
Why Buggy Software Gets Shipped
Easy. Because it's nearly impossible to get software bug free. Add time constraints and pressure from above... Even when software is close to bug free, people always want enhancements, new bugs are introduced..
The best Linux distros test their releases to death, and still require and release regular bug fixes. And that's the difference, really, not to get into the OSS/closed source debate, but it's all down to how you deal with the fact that software is buggy.
QA is not there to find bugs for fixing. Sure, they may run into a few here and there that are worth the time to fix before the product ships, but by and large the major bugs are caught while the sources are still hot on the developer's local tree. The bad ones that make it to QA fall into one of two categories: 1) bad developers and 2) bad architecture/design. Both of which are great topics for conversation, but not the problem at hand.
What we are talking about is QA and its role. It's role is to identify and label as many bugs as possible. Ideally, no bug would make it unknown to the wild. Even heinous bugs that wipe out user data and go on to crash international banking servers require no more than identification and tagging by QA. What QA is for is to make sure that all behavior by the product is predictable.
Now, one byproduct of making the product's behavior 100% predictable and reproducible is that it becomes easier to write the fixes for those features which are labelled as bugs, but that's a byproduct of QA, not its main reason for existence.
If you work for a company that thinks that QA is supposed to be finding bugs for fixing, you're most likely working in a place where the QA team is stressed out and the product cycle is longer and less productive than other places where QA's role is clearly defined as the assurance of the quality level of a product.
I do care about bugs that crash the program, and I really care about those that cause data loss.
If you knowingly ship code that causes data loss, you are morally responsible for that loss, especially if you don't warn anyone about it.
Disabling that dysfunctionality is always preferable to destroying customers' work.
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.
Marketing , Management and Money
The only things certain in war are Propaganda and Death. You can never be sure which is which though
I agree that for a non-mission critical type of software, bugs are acceptable. As long as there are workarounds (e.g. avoid doing things that cause the bug to occur), it would be ok.
However, for mission critical software such as medical devices that deals with raditions output or heck even slot machines, bugs are unacceptable.
A good example is the Therac 25 where due to bugs, it actually injured people. http://www.ganssle.com/articles/disaster.htm
I hope the poster of this article or anyone who is in group 1 will never work on any mission critical software.
So there's no possibility of a bug whose cost to fix is so high that it doesn't justify the benefit?
Articles like these make me sad that slashdot doesn't allow the posting of images in replies. Had this been on fark.com, this thread would be full of Ric Romero images.
Luckily Ric's wikipedia article suggests a textual equivalent..
"Determining which bugs to fix should take into account some manner of cost-benefit analysis?! Thank you, Captain Obvious!"
SCO employee? Check out the bounty
It is in the best short term business interests of the people making the decision to ship software with some bugs NOW rather than ship perfect software later or never.
You're going to announce that you plan to ship xyz new feature on some date well before that date occurs.
In this business, you make the announcement for the same reason as in any other business. You don't want your customers to choose an alternative that precludes the necessity of buying from you.
These schedules are always aggressive. They typically assume no bugs passage release test on the first try.
Managers who develop these schedules are not stupid. They just have to respond to business as well as engineering requirements.
Development and debugging are always behind schedule because this is not realistic.
So, you string the Customer (one company or "the market"; doesn't matter) along with promises and betas, but eventually, they demand the product. Pressure is high and the Customer says give us what you got. (And well scream bloody murder if it's not right, and we know it's not right, and it's your fault, now, give us the f---ing software now!)
And you ship, because once you've gotten to this point, to ship is a better business decision.
QED
PS
You bet your ass I'm posting this AC.
When I was a lead tester at Atari, there was 3,000+ bugs for Backyard Baseball GCN and less than a dozen open minor bugs when the game shipped. Some people considered 3,000+ bugs to be a high number for a GameCube title. For me, that's being thorough. (Which we had too since the programmers loved inserting phallic imagery into a kids game.) I'm looking forward to seeing how Backyard Baseball 2007 GCN stacks up when it's released next month. My assistant lead tester and I (we both no longer work for Atari) are planning to tear it apart. I just hope I don't have to submit a report to change the ESRB rating for any inserted phallic imagery. From some of the screenshots I've seen so far, we may very well find something.
Whats really frustrating is getting people from Group 1 that know why buggy software is delivered to customers, but start to accept this as normal practice. This especially hurts in the aerospace industry when we get crossover managers and software developers from Group 1 that can't understand why we don't release buggy software intentionally and spend a lot of time dealing with their crappy code or improper schedules because they think software verification is a luxury item that is unnecessary.
I would prefer to at least know the things "you" (microsoft, etc. whoever) know that are definitely broken features of the product. I'd like to see "You can't do this, but here's the workaround" and put that info in some kinda place. Programs used to come with user manuals that told exactly how to do things. Now they pretty much don't come with that stuff, which means I should be able to do anything? Nope, some stuff won't work, but no one told me the Proper(tm) way to do it, so I have to go spend another hr on the internet looking it up. That's broken as hell! Just tell me how to do it the first time.
Also, the scope of the bugs that exist is super-wide now. There were always some kinda errors in a program that are weird, but main features being broken (especially becoming broken by other installs from same company) is just not acceptable. Sure, a "buffer overflow that is really complex to implement" probably matters to me, but way less than seeing "windows media cant find codec" on a WMV video I need to watch for class in a school lab, on a PC that I can't install anything on.
stuff |
I see all the usual flippant comments from the /. banana gallery about M$, but what does buggy software have to do with "commercial" software? All software has bugs, closed source commercial to open source free. While it's popular to only hold up specific examples like IE vs Moz/FF or Linux/GNU vs Windoze, fact is that I have not personally witnessed any better quality coming out of FOSS side vs the commercial side. Like with anything else, several factors play into why software has bugs, most of them focus on the abilities of the developers themselves (give me good developers on a tight schedule vs average/crappy developers with all the time in the world).
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.
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.
while ( ( your_budget ) > ( Estimated_liklihood_of_this_bug_being_a_problem_to _users ) * ( The_foreseen_cost_of_recovering_from_this_bug_if_i t_were_to_be_a_problem ) {
fix_bugs();
}
ship_product();
My work here is dung.
The very fact that this discussion arises at all tells me that profitability is of more concern than quality in the commercial software world.
In the Free Software/Open Source world, that excuse doesn't exist, so what is it? Laziness? Hubris? Apathy?
"My God...it's full of trolls!"
Hahahah - you have obviously underestimated the irresistible power of the Quarterly Balance Sheet.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
All software ships with known bugs - if it doesn't, you are either not testing enough, or are only shipping tiny programs. At some point, commercial reality has to come into it and you weigh the cost of fixing the bug against its impact.
Erveytnhig hmuans do has bgus. Soemohw we mnagae to get aolng.
In
1) *MOST* cases, the
2) *VENDOR* needs the revenue in order to meet unrealistic sales forecasts and
3) *PROFIT* now, bugs be damned.
If you don't, your
4) *SHAREHOLDERS* get
5) *PISSED* and run and the
6) *COMPANY goes TITS*
The stock market plays a HUGE role in why things suck.
it just shows that being a programmer nowadays is just
...
another job you can do. write software, earn money.
no more moral grounds, or bonding with the software or
the resposibility of the "thoughts of a computer". very sad.
just throw together some "software" (my god!! "builds on
sql server") and sell to some idiots.
just wondering when this economical bug will hit the
manufacturing industries. i think some wittier slashdoter
can come up with horrendous outcomes with this "never mind
we sell products with bug" mentality in the food,
pharmaceutical or machine industry
"yeah, we KNOW our sausages; we dont eat them"
"yeah we build that airplane; but we do fly in them"
If at first you don't succeed, redefine success.
The problem with vendor honesty is that it backfires on the vendor.
Let us suppose that WidgetWorx version 1.1 gets shipped. Inside the package is a list that says, "at the time of shipment, these are known bugs/shortcomings/issues."
An ambulance service that uses WidgetWorx for their dispatching service, and something goes wrong that leads to a patient dying. Said patient's estate could hire a savvy lawyer who would make a wrongful death claim against the ambulance service for "using a software package with known defects, thus indicating negligence." Even if the package did not have anything to do with the patient's death, it would be an indication of careless behavior and "lack of due diligence" by the ambulance service.
The ambulance service (or its insurance company), in turn, would sue the manufacturers of WidgetWorx to recoup their losses... and the list of issues would make it a slam-dunk.
I'm not denying that "vendor honesty" as you describe it would be a good thing in a perfect world. Unfortunately, this world, like my grammar, ain't perfect.
Strike while the irony is hot! -- The Freethinker
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.
There are experts in every language that are very capable of emulating almost anything--without many bugs
You, apparently, did not agree with my assumption. That's fine. Just don't accuse me of throwing in irrelevant information in an attempt to sound like an authority on the matter who is important or intelligent. I know that I am neither and it is insulting to say that I would be so pretentious as to fake it or even desire it.
My work here is dung.
Quarterly sales figures and bonuses based on projections that must be met.
If anyone is more interested in this subject, Mark Minasi wrote a good book on the subject called "The Software Conspiracy".
eom.
People do stuff because they can do that stuff.
Ideally they do it because the trade offs are acceptable.
In software there is some that is very buggy, some that is nearly bug free. This is mostly driven by what the customer is willing to tolerate.
It is better to ship a product with a known quality level than to ship a product full of surprises.
So, if all the known bugs were fixed, then the product would ship but be full of surprises (since we assume it has bugs we don't know about).
But if you don't fix the known bugs... the product would ship full of bugs and surprises?
hmmm...
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
Although Mr. Sink makes good points about the need to ship products with a certain level of minor bugs and do a constant analysis of priorities to continually improve a product, which may lead some minor bugs always open, original architecture design has a big impact on the ability to fix bugs.
For example, Mr. Sink's two bugs that he cited show two things:
1. Improper design of the business logic to database connection by locking themselves into a closed-source, expensive, proprietary database system and using proprietary extensions offered by such.
2. Developing and testing for only one platform.
If originally they had designed their architecture to not rely so heavily on internal mechanisms of SQL Server and kept in mind that they might want to make a change at some point, the evaluation of whether to fix the first bug he cited would be quite different. If they had spent just a little time upfront thinking and testing cross-platform development design, the line endings bug would be a non-issue and overall code quality would probably improve.
Therefore, his analysis of bug prioritization makes sense once you get to the shipping stage. However, it is not an excuse for shoddy design, which causes some bugs to not be fixed because of the high level of cost and risk it would now take because of that poor design. An indication of the overall quality of a codebase is how easily bugs can be fixed. Given enough time, the market (in non-monopolistic product niches) will sort out those that can fix their bugs because of good design from those who cannot.
It's that so many companies ship with flaws that would be unacceptable anywhere else.
Would you ship a doorknob for an outside door that could have the lock so easily breached that it's as simple a matter as inserting a slot screwdriver into the keyhole and turning?
That's what gets shipped by many companies- those sorts of flaws.
And it's the mentality of the first group (The "there's always going to be bugs" crowd he's talking about..) that causes the stuff to ship that way. Sure, there's going to always be some issues somewhere in a complex system- but the goal is to do your level best to reduce those to as close to zero issues present as you possibly can, dealing with problems in the order of their severity.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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.
As he or she is in group 2.
I remember attending a meeting at a conference held by one of my previous companies. The head of marketing had this to say. All software has bugs. If it doesn't have bugs, then it isn't software. So true.
My work here is dung.
Good idea! You go first.
What do you mean? Release a list of bugs in my next post prior to posting it?
I'm not a software vendor!
There are shills on slashdot. Apparently, I'm one of them.
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?
With users, marketing, managers, and developers all being carbon based life forms (debatable regarding managers, but work with me here...) there is guaranteed to be imperfect communication between the groups. What we call "bugs" are a manifestation of being human. As as been noted, the question is not why software ships with bugs, but how to deal with the problem. I have recently come around to the conclusion that Eric Raymond's "The Cathedral and The Bazaar" is pretty accurate, and the open source model comes nearer to producing high quality code for many software projects "With enough eyeballs, all bugs are shallow." -- Linus Torvalds
As the article states, risk is a big factor, but it is not the only reason/excuse.
More reasons/excuses:
- No one from the company really cares about the final product.
- Developers either want the perfect design or just want to get the job done good enough.
- Upper management just want features to stay ahead of their competitors.
- QA/testers can yell all they want, but they eventually give up because no one really listens to them.
- Project managers just want their track record to stay good.
- Call center/support people have no idea what new products are coming, and they do not want to deal with anyone else.
So, companies just throw out whatever product they have. Therefore: assume nothing good about software/hardware packages (and that goes for medical and financial products as well!).
- No company wants to spend money on bug fixes that get no quick return on their buck.
- Bug fixes to the final product involve getting almost every party in the company to a particular bug fix. I have spent 1 minute writing the code to fix a bug, and about 4 months in work time (over the course of a year and a half) trying to push this fix through. The result was that some previously unknown vendor stopped the change because they thought the risk to their small one-and-only product was too great.
The problem is that some people percieve that giving people buggy software is somehow unacceptable. When you look at reality, this is far from the truth. People favored Ubuntu over Debian because they felt Ubuntu was newer. People intentionally run ~86 in Gentoo because they care more about newer software than the bugs that might contain. People constantly enter public betas to try out new software. Look at the number of people running Vista on their primary desktop. I'm sure you can come up with plenty more examples. People pick features over correctness.
The biggest trouble that arises from this market force is a lack of transparency. Ideally, the "release early, release often" approach treats the users as a large software testing team. Instead bug reports are difficult to submit, and almost always kept private; a publicly disclosed list of known but unfixed bugs provides critics and competing software ammunition. Current market approaches offer no incentive to turn a community software improvement practice into an established transparent process. Once I've purchased software from a vendor, the only obligation they have to fix bugs is related to PR and lawsuits of unmerchantability. Even software subscriptions as currently envisioned don't really address this. You pay a monthly fee for the right to USE the software at all, rather than the right to upgrades, patches and fixes. Stop paying and you can't use the software at all! Of course, this might also encourage companies to test even less than they do currently, and charge customers both time (to identify the problems) and money (via the update subscription) for the fix.
I Browse at +4 Flamebait
Open Source Sysadmin
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 can't quite place my finger on it, but if the author is attempting to say that the major software companies that tend to release buggy, shitty software on a regular basis are being responsible corporations, he's full of it.
Yes, products should ship with bugs. Creating a bug free product isn't worth the time/investment. If you get 95% of the way to done, and the remaining 5% is going to occupy 70% of your budget, don't bother.
At the same time, software engineering is NOT more sophsticated than, say, aerospace, or automobile, or robotics, or any other area of modern engineering.
I'd be MIGHTY pissed off if my car was as reliable as an MS product, or if I had to put up with the same bugs, year after year (transparent PNG, anyone?)
Apple releases buggy software. Linux distributors release buggy software. Microsoft releases buggy software. NASA releases software with bugs (I can't say that NASA software is "buggy" with a straight face). But does that mean they are equivalent? Of course not.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Would like to thank Microsoft for setting the standard for software delivery at beta. We sure wouldn't get much shipped around here otherwise....
The real reason buggy software is shipped is because it isn't all written in Perl.
Some industries are held accountable for shipping "buggy" products. Here are examples of two recent "bugs" that you may have heard of:
http://en.wikipedia.org/wiki/Vioxx
http://en.wikipedia.org/wiki/Bextra
If software companies could be held liable in the way pharmaceutical companies are held liable, we would *never* see shipping software with 5-digit bug lists.
The internet makes patching software a breeze.
Do you remember back to a time when virtually NO software / games had major bugs? Yeah, that's because patching software by snail mail with floppy discs was a costly and unpractical nightmare, so you had to get it right the FIRST time.
If you read the article, there is a weigh-in against RISK. For all those who say NOT IN MY INDUSTRY - NOT ACCEPTABLE FOR MISSION - CRITICAL - well no shit. That falls into the RISK category. If bugs are unacceptable for the purpose of the software - ie - patient monitoring then every effort will be made to ensure it won't happen.
Geeks of the World, Unite!
You know, the article would have gone down easier if I weren't dealing with bizarre issues in Vault right now regarding items getting stuck in the queue and database corruption of files. Its at the point where I might switch to SVN, and I'm not a CVS/SVN fan at all.
This guy gets it, and the others responding to this thread do not. There is no reason to ship with known bugs, shipping with known bugs doesn't mean you have good testing, it means you have lousy developers and poor quality.
The fact that consumers tolerate it means you have a good business model, or a good marketing team. But your still shipping crap and your developers (and managers and quality) still suck.
In this day and age, the goal is to make a quick buck, meet your quarterly goals, collect the bonus and score another job based your great quarter. Downtime usually isn't an issue so you wind up with Microsoft spreading into desktops and datacenters. It's cheap and you can hire a reboot monkey to admin these systems. Of course we can replace the big box and the guys who've kept it running 7x24 for the last 23 years without any outages. They cost too much to keep around anyway and don't have any colors but green or amber.
Bill Gates understood that you don't need to be better, you need to meet the minimum standard and be the low bidder. With the introduction of Windows, the minimum standard creeps lower, allowing his next product even more market share. We're beginning to see a backlash with security and reliablity becoming issues again.
If a VAX booted in 1983 can run an application without a reboot for 17 years (Year 2000 shutdown) why doesn't can't a modern system stay up for week?
Project managers under pressure from execs to push out a product. Mostly marketing execs that promised something to higher ups in order to gain favor, bonuses, and raises, and potentially promotions.
Project managers create unrealistic timelines. This pressures programmers and testers.
When products are tested and show problems they determine if a bug is a showstopper or not. If it is not and they can't fix it in time they ship.
Do these people make a conscious decision to ship buggy code? You bet they do. They make them on purpose and in their favor, every time.
Some unknown bugs get through by accident. No ones perfect.
But, every product goes out the door with bugs that they know about and have no intention of fixing right away, if ever.
This absolutely is an issue with the project manager making unrealistic promises to the higher ups in order to gain favor, money, and promotions. I worked for a company that produced software and we knew there were major bugs and these were shipped with the baggage that the tech support would have to deal with the issues.
You can lead a man with reason but you can't make him think.
Software will stop being buggy as soon as people stop putting up with it.
So true. And your 'flamebait' is a perfect example.
Indeed. You should never ship the sofware with known bugs. Just change the documentation such that "known bugs" become "features".
Yeah? Well I think you're overrated too.
...there's a huge difference between a bug and an enhancement request. I don't care if I'm the only frigging one that's triggered that bug, I get quite pissed when your tool isn't working and the crap I get back from support doesn't contain even a workaround only "This is a confirmed/known bug, blehbelbhe" then put me on hold till 2010. That your development team isn't going to implement a feature at my whim is something quite different, not to mention doing the same "analysis" makes no sense.
Key points for an enhancement request include such things as "Is it part of the direction where we want to take the product (strategic value)?". Sometimes there are hard calls on the path you want to take, and sometimes you want to take them even if the stepping stone doesn't justify it alone. Sometimes it's "the big picture" that needs work and it makes no sense to implement this little feature because we want to replace what it runs on top of. There are so many things like that which don't go into account when fixing bugs.
Live today, because you never know what tomorrow brings
It's amazing how thorough application testing can be when you've had 10 or 15 years to develop a set of automated regression scripts, when the design of the application is modular, and when the basic environment in which the application is running has been relatively static.
All of those things are true in some mainframe environments. The Unisys 2200 EXEC, for example, is largely unchanged (from an application program's perspective) since the late 1960's. That removes a lot of variables related to the external environment that a Windows or Linux developer has to take into account, making the testing process a lot simpler.
Combine the above with a decent QA process and competent developers, and you can greatly reduce the number of bugs present in even very large/complex products on a mainframe.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Instead of asking 'why don't we ship shrinkwrapped apps that are not bug free', I think we should be asking this larger question:
Why do we ship shrinkwrapped applications at all?
The model we are using is all wrong. Instead, we should be gearing our application lifecyle to handle iterative (recursive) development - releasing early and often via the network. Many pay-to-play games successfully use just such a model, updating content and patching bugs via uploads.
Add to that an agile process approach coupled with a design philosophy that emphasizes simple modules (that can be tested more completely, encorporating clearly defined APIs that don't allow undefined results to occur when external modules attempt to pass bad data) and you have a winner!
Thankfully, there are few developers who understand this concept - their continued delivery of faulty applications, that then takes more money to 'correct' (e.g. you buy the next version - which in fact has its own faults) makes me look like a CS god in comparison - and keeps me in business in areas where there is little tolerance for buggy code.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
You mean like these?
As always, all IMO. Insert "I think" everywhere grammatically possible.
Sure, no product of any reasonable complexity will ever ship without a single bug. For that matter, no sufficiently complex product will ever ship with all the known bugs fixed. In my opinion, however, developers and product managers have been come way too cavalier about shipping product that contains known serious defects. Too much emphasis is placed on features to the detriment of quality. It would please me if every major commercial product tacked on 2-4 months to the end of every release cycle and dedicated it solely to bug fixing. This would be on top of whatever other time they already devote to this task. They're going to do this work eventually anyway, when those bugs are found by customers instead of in-housr testers and developers.
Alot of it really depends on if you really need to meet the deadlines to make money that quarter or not. MS is so big and does so much in sales that a delay does not kill them, but most other software companies are not as big and need to make money so they ship buggy software instead.
Only 'flamers' flame!
Does slashdot hate my posts?
The FDA has an acceptable amount of fecal matter in food! This is not a lie. This is the mentality we've grown into thanks to commercial/industrial interests who don't want the cost of running a tighter ship.
Is it possible to have bug-free software? YES IT IS! If a bug can be fixed, it can be avoided. If it hasn't been avoided, it can still be fixed before it's allowed to ship. But now, "Group 1" is adding the "acceptable amount of fecal matter" in with our software.
If you knew for a fact that there was fecal matter in your food, in ANY amount, would you buy it? I'm thinking no. I know my answer is no. I think that every product that is released with a measured acceptable amount of fecal matter above ZERO should be required to be disclosed on the label. And the same should go for software as a consumer warning. Something in red and yellow stating "at the time of publication, this software is guaranteed to have no more than XXX known software defects." And then shoppers will be able to select products with the lowest possible number of known software defects.
I think if software makers were required to disclose this on a label visible PRIOR TO PURCHASE, they would have sufficient incentive to keep those numbers closer to zero.
Nobody on our team intentionally creates new bugs. Yet we have done accidentally. Does anyone else find it appropriate that he made this error in this pair of sentences. Had he not have added the second sentence he wouldn't have introduced the error. He should have written:
"Yet we have done so accidentally."
or possibly:
"Yet we have accidentally done just that".
I'm sure you can all come up with your ways to fix that bug.
Having actually RTFA, the author seems to make no distinction between feature requests and bugs. His first example of people wanting the product to run using something other than Microsoft SQL server isn't a bug: It's a feature request. His second example looked like a real bug: People using the company's product actually couldn't use it because it mis-behaved when it should not have.
He treated them as if they were an apples to apples comparision in terms of the decision of whether or not to 'fix' when in fact he was comparing a feature request to a bug fix.
Regardless, I found his entire argument weak. Software makers routinely ship software which, if it were a physical consumer product, would get the manufacturer their asses sued off for product defectiveness. I doubt an auto company would get very far in court by saying "the tires only fall off occasionally while driving." The stunning thing is that software companies don't get sued very often. They have done a phenomenal job of persuading the consumer that it is only to be expected that occasionally the steering wheel locks and the car drives over a cliff.
...and all this time I thought they were added features!!
wg
As products in general get some complicated they are prone to "bugs". My inlaws purchased a new fridge with many many functions. But it also has a bug, the light on the outside door gets brighter the brighter it is in the room. When the light is off in the room so is the light and there is no way to trigger. In software it may be ok to have bug, especially since anything big can be patch. But a buggy fridge?
Otherwise, Joe Sixpack will always buy the product that does not tell him about the known bugs. "Gee, Mable, the Microsoft version has 1000 bugs listed, but the Happy Lucky Kitty version doesn't have any bug list at all. I guess we better buy the one with no bugs!" The first company that advertises its bugs probably goes out of business or has a stockholder revolt leading to new management.
FOSS projects publish their known bugs in order to encourage outsiders to fix them and feed back the code. Different ecosystem.
How silly that 2 groups thing sounds.... however in the context of the discussion, there are actually 3 groups.
The 3rd group being the largest. It's the majority of the population that is too concerned with war, genocide, starvation, lack of water, or poverty to care, or even be aware of computers or software.
I know that this is way off topic, but the opening line of TFA kind of rubs me the wrong way.
BTW, buggy software is shipped because of inadequate testing or fix time. Though there are a lot of reasons for this (management/client pressure to ship, lack of budget/poor planning, poor test scripts/procedures, feature creep.......)
wbs.
Huh?
Hoo boy, here we go again. In any other engineering discipline, releasing a product with so many bugs^h^h^h^hflaws would be completely unacceptable. Yes, a certain number of errors will slip through. This is inevitable, and this is where risk management comes into play. But by and large, the software industry isn't even to the point of risk management, which implies a certain amount of rationality in activities like setting deadlines, deciding on features, etc. The status quo is anything but, and this poor management is the main reason bug counts or so high. So, yes, some bugs are inevitable, but there's no good reason for high impact bugs that a large number of users will encounter to be considered an acceptable norm.
Theoretically, there is no language that is more or less prone to bugs than any other language as understood in Turing Completeness.
I call bullshit.
People keep using "theoretically" in this way, and I'm not sure what they think it means.
For example, imagine a language "Java--" that was exactly the same as Java, but didn't support Strings (if you want to process any text, you have to implement that yourself, and good luck with Unicode) or garbage collection (free everything you create, or it gets leaked).
I think we can all agree that Java-- would be "more prone to bugs" than Java.
So whatever "theory" you're using to make these "theoretical" claims is so weak it can't even stand up to what is perhaps the simplest argument possible. What "theory" *is* this, anyway (that any Turing-complete language makes it equally possible to write a bug?), and what good is it if it's not at all true?
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).
Oh, right, because if something is mathematically possible two different ways, that means they're equally likely, huh?
Some languages are more prone to bugs. That's life. Deal with it.
No, I meant like products people actually buy, not products that have over 90% of their users downloading them for free. You've linked FOSS projects not commercial vendors.
I think your point's still valid, though... open source projects (especially GPL projects) benefit from people knowing about bugs in their code, because that increases the likelihood that somebody will fix them and send in a patch. Closed source, on the other claw, has commercial incentive to hide bugs as much as the customers will allow.
I know that the readership of slashdot are obviously more computer literate than most however, I feel that we should acknowledge that there just might be another group that would be people who don't know that software exists. In fact there is a large group (probably larger than "groups 1 & 2" combined) that have never even touched a computer. Just because we are all well aware with the problems that there are with software we can't be oblivious to these disparities just because we're fortunate enough to be able to rant about software bugs from the comfort of our own personal terminals.
I would define the term bug as "undesired behavior" and I suggest they be thought of in this manner. I will also make the statement that no piece of software can be garunteed to be free of undesired behavior due primarily to the above analysis of them being amazingly complex machines with a large state space. To take a stab at it mathematically, this browser (Firefox) is operating with a 48,604 Kb memory footprint (I have many tabs open). That's 49770496 bytes or 398163968 bits. Each bit can be on or off meaning that for the amount of memory my browser occupies now, there are 2^398163968 different possible states for any similar sized application running. Now, to add even more complexity, that state space adjusts according to what the application requires for memory.
Clearly 2^398163968 states are too many to be in during the current lifetime of the universe. However, you can use formal logic to prove which of those states are valid and also prove that the program can only move into valid states. Most widely used languages have (multiple) formal proof systems available. Even assembly language has a formal proof system. Look up proof carrying code and check out examples like fast network filters written in a proven subset of assembly language so they can safely run in kernel mode. Formal proof systems can even handle time complexity and require programs to terminate within a certain number of operations.
The problem is that most programmers aren't smart enough to use the formal proof systems and generate their own proofs. Thankfully compilers are able to do most of the hard work so long as the language is type safe and a few predicates are provided by the programmer for initial and edge cases. Even pointer usage can be proved correct, often with little or no runtime overhead for pointer validation.
So why aren't programmers flocking to these new systems? They'd have to take responsibility for the code they write, and no software company wants that. Expect Free and open source software to be the first to bring you formally correct, bug free software. Bug testing is a matter of running the proof checker on submissions and merging them if they pass. The formal specification that the program has to obey will become the only place where changes are made to the actual function of the program, and since it's a formal specification automated tools can be used to find edge cases and unexplored behavior and write new predicates to control it.
I'm firmly in Group Two even though I am a programmer and still write buggy code. It's a solvable problem, and I'm working on understanding proof systems so that I don't have to write buggy code anymore.
Let us know when you've written a non-trivial application and actually shipped it.
no, No, NO!
The world' six billion people can be divided into 10 groups. Those who know binary and those that dont'!
Quality arguments of this type are not confined to software alone. You will find the same reasoning in hardware engineering, and even in process engineering for manufacturing plants: There must be some balance between the benefit of solving a potential problem, and the adverse impact of changing systems in ways that often make them more complicated. So on the whole I find Sink's position reasonable enough.
Consider this one, however:
Vault's backend makes extensive use of features specific to Microsoft SQL Server. Contrary to popular belief, SQL isn't portable. Adapting the backend for any other database would take months, and the maintenance costs of two back ends would be quite high.What this probably means is that Vault is relying on features highly specific to the Microsoft SQLServer engine, and that these external dependencies are not isolated behind some interface or localized in a specific module, but scattered all over the entire software. That's not a bug; that is a major design error. It probably implies that whenever Microsoft changes SQLServer in a version that is not 100% backwards-compatible, Vault's customers will have to put up with a lengthy series of minor and major bugs until they have all been ironed out. And if this is their design pattern, that may also be true for every other external dependency that they have. (Their line ending problem suggests as much).
As a potential customer, I would not care much about the length of the bug list, which actually says more about administrative neatness than about the stability of system. But I would be greatly worried about design errors like this, that fundamentally undermine the future of the system. If I buy it, it might turn out to be a millstone around my neck. And if a system is badly designed, it is also likely to contain more bugs and be less stable, because probably even it's programmers do not understand how it works.
Good fundamental design is still at the heart of develivering quality software. There is no replacement for it.
Advice: Share your software's source code freely, and it will get better as you sit around poolside drinking lemonade.
Parent: "Trying to come up with a featureset for some vague "target market" is a horrbile way to write software...Software is unique because it is both engineering and design at every phase of its creation... don't work in a closedsource / many customers environment... it's bad for the brain."
I just made a new friend. It is an almost-perfect tradeoff: the larger your potential market, the more difficult it will be to service it profitably, because of the proliferation of situation details/uncertainty.
On the other hand, if you develop software for its use-value to you, rather than its exchange-value, you deal with a single set of requirements. Free the code, and this use-value can only increase, anywhere from not-much to Tons, depending on how common that set of requirements is.
My turnips listen for the soft cry of your love
To my left I have a gameboy advance SP with Mario Bros 3. Loaded.
To my right I have a wintel PC runnig Windows XP.
Both are chunks of hardware with some software loaded on it.
Both are mine and I have years and years using them.
One needs zero maintenance and is pretty much bug free and
the other one needs more nursing than a premature crack baby.
The gameboy in my own personal experience is bug-free because:
a) it's small in size and functionality.
b) It only tries to do one thing right (play games).
The PC in my own personal experience is the paragon and birthplace of
bugs because:
a) it's too big in size and resources for the bottom-line end-funtionality.
c) It does a million things half-ass.
Over specialization results in a slow death.
Over flexibility results in unpredictability and possibly, sudden death.
The PC must go.
- these are not the droids you are looking for -
IMHO this article is plain wrong in the way to tackle the issue.
So, according to the FA, one would not fix all bugs because:
So basically, the article misses the point and mixes bugs, feature creep and unforseen requirements. As a lead developer, I never accepted that the industry I work in can ship products that simply don't work the way they should, or have so much bugs it makes people laugh. It is also an insult to the paying customer user who knows nothing about software and can't work its way around them.
On the other hand, computer scientists know that no program can be empty of bugs. It's been demonstrated. We should live with it and make the best of it.
If you have open bugs, then you have potential security problems. (At least with OS code) If the bugs are well understood, then fix them with low cost, and little risk. If the bugs are poorly understood, there may be buffer overflow issues and other security problems. (So fix those too)
That's what makes Computer Science different from other fields, like building houses or bridges. What we understand is easy (or provably impossible). What we don't understand is difficult.
If something is easy, I can write a script to do it for me, then I just issue one command and viola, it's done. An engineer may know everything there is to know about building bridges, but it's still a long, hard process to get one built.
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
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.
Of course, I'm in <fnord> group 3 </fnord> (never mind the fnords, nothing to see there, just move along...)
If you produce a physical product which malfunctions you are liable for damages it causes. Why is software a protected class of products from being held responsible for its non-performance?
I don't work in the software industry, but I do work in the animation industry, and it's probably the same principle with software. Short production schedules, limited budget until the product needs to get out the door, incompetent people who are there due solely to the length of their resume, ineffecient scheduling of people's individual tasks, and the fact that the product you're producing could be sent out uncompleted and still sell are all reasons software has bugs in it. Making software isn't like building a bridge, which is what many people love comparing it to. If a bridge falls down, people die. If software crashes due to a bug, people learn to work around the bug.
The fixing non-critical bugs stage in software development is the equivalent of the "finessing" stage in animation. You can finesse a project forever, fix bugs, add features, etc, but there comes a point when it just has to be put out the door.
Don't trust a bull's horn, a doberman's tooth, a runaway horse or me.
Someone above wished that vendors would at least list known bugs. The problem is competition. If you list bugs and the other guy doesn't, you are going to get creamed.
But, look at the Drug industry. They *HAVE* to list known side effects. SO *everybody* does. Then its not a problem, because you don't have Squibb listing side effects but J&J saying "our product cures cancer, saves the whales, and protects social security!" Both of them list side effects.
Marketting takes advantage of the consumers dream world of bug free software.
In a way, they have to. How many average Joes would buy a new 2.0 version of software, if they realized it probably has more bugs than what they already have? You would see upgrade times in decades instead of years...
If computer power/memory growth ever slows down, so that a PC bought today is still good to play the new games ten years from now, then its bad times for most software vendors. Nobody will upgrade. They will buy new games, sure, but not new applications or new O/S. We could see Microsoft get smaller than content companies like EA or Blizzard.
A = testing and development
A is expensive.
Fixing bugs that customers find in software is much cheaper than A.
Fixing bugs that customers find in physical products is much more expensive than A.
From a customer point of view:
Software product breaks. Software bugfix is free. Your bug goes away. Happy.
Physical product breaks. A new physical product is the full cost of the original. Not happy. Buy from a different company.
The masses are the crack whores of religion.
FOSS projects publish their known bugs in order to encourage outsiders to fix them and feed back the code. Different ecosystem.
Good point. YARTSOS (Yet another reason to support open software)!
There are shills on slashdot. Apparently, I'm one of them.
These are ideas adopted and rewored from Ross Anderson's paper "Why Inofmation Security is Hard" (Network Externalities) First, the value of a product to a user depends on how many other users adopt it. - The more people use a typical network, the more valuable it becomes. Second, technology often has high fixed costs and low marginal costs. - The first copy of a chip or a software package may cost millions, but subsequent copies may cost very little to manufacture. Third, there are often large costs to users from switching technologies, which leads to lock-in. - Such markets may remain very profitable, even where (incompatible) competitors are very cheap to produce. All three of features leads to a "winner takes all" market structure with dominant firms. It is extremely important to get into markets quickly.
It's not the bugs that bother me, it's the design flaws that get baked in stone and cause the biggest computer security disaster ever, and when the DoJ tries to get Microsoft to do something for unrelated reasons that would solve the security problem, Microsoft doesn't go "Ok, we can use this as an out, and get great PR out of it", they fight the DoJ to the brink of getting the company broken up and beyond and only get saved by a change in administration...
That's what bothers ms.
IIRC, Steve Wozniak wrote the original Apple Monitor code in a now-legendary all-nighter, and anyone who took the trouble to disassemble it from that night onward saw Revelation. That night joins a short list of epiphanies that lifted the human condition forever after.
So it's possible to write bug-free code. But! If Quality Control mattered, geniuses would be hired to test software, as well as write it. If Customer Support mattered, geniuses, not average schmucks, would answer the phones and take the flamethrowers in the face.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
... there are 3 kinds of software developers. Those who know how to count - and those who don't!
"[W]hy are programs so buggy? A general answer has already been given: because it is human nature to push until we get into trouble -- and then blame our tools. We load the elephant with feathers until the elephant collapses, whereupon we conclude that feathers are too heavy for elephants. No matter how amenable software is to our efforts, it can overwhelm us if we pile the code high enough -- and we often do, because it's so fatally easy. But the special reason for software's bugginess is that we almost never demand that it be bug-free (I use "demand" here in the economist's sense: not just desire, but desire backed up by ability and readiness to pay).
"Software manufacturers are rational economic actors; if they can sell us software without going to the expense of thoroughly debugging it, they will. The copy of Microsoft Word that occasionally drives me crazy cost around $200; if Microsoft had been forced to debug it thoroughly before releasing it, its price would be closer to $2,000. Would I pay that much for a version that I could be sure would never crash at a critical moment, losing hours or days of my work? Probably not; apparently, I don't value my sanity that highly. I am neither blaming anyone nor apologizing for anything; I am simply reporting Microsoft's behavior and mine, in the belief that they are typical of just about all software developers and computer users. In a word, we have buggy software because we consumers won't pay what effectively bug-free software would cost.
"The reasons why software is almost always buggy are not inherent in the technology and thus inevitable, but spring from human choices and practices that we can understand and could change if there were a compelling reason to do so. Those habits include piling the code on until it overwhelms us, and taking our chances with buggy software in order to get it more cheaply. Both problems could be overcome if we wanted to overcome them badly enough."
[Mark Halpern, "Buggy Software and Missile Defense," The New Atlantis, Number 10, Fall 2005, pp. 47-57.]
I know it's easy to blame the internet for everything these days, but bear with me. Ever wondered why older "pre-internet" software was less buggy? Ever wondered why Playstation, PS2, Gamecube games are pretty much bug free? The answer is, there is/was no easy way to deliver patches, so QA was much more important, as it would cost real $$ to fix thingd after a product ships. These days, it's "ship it, fix it in the service pack", even worse, cutting back on testing, safe in the knowledge any issues can be easilly addressed. You can bet the next generation PS3 games will be more buggy than PS2 games, as the console is gaurenteed to have a HDD, and hence games can be patchable..
Well, even then.
Consider the following. A hospital has an old bug-free IT system that unfortunately does not do enough to relieve the medical staff of clerical work, causing say 10 deaths a year.
A new system has been written that would do more, saving 5 of those 10.
But it has bugs...
Do you release or not?
The number of bugs is only one side of the issue. The severity of the bugs is just as, if not more, important.
The most serious bugs I've seen almost always relate in some way to crappy state management because some fresh-out-of-college-n00b distributes state to every "object" they've constructed in their over-engineered seven-levels-deep nightmare design.
In a well designed system, bug severity is limited to an interruption of service, and loss or confusion of data is very rare and carefully mitigated by the design.
If state is preserved and transacted correctly, then some hoser who codes in divide-by-zeros will find it hard to violate the data integrity. The very best systems will reset, load the last good state, and continue merrily as if nothing happened.
Have you ever seen a bridge where 1 broken bolt causes the thing to collapse?
Physical processes tend to be continuous and small failures in most areas can easily be countered with general design principles.
Software, on the other hand, is discrete with an enourmous number of paths through the system. Small failures can lead to other small failures, or to gigantic failures, there is little correlation between the size of the initial fault and the size of resulting problem.
We know how to produce fault-less code, test all possible scenarios. But this tends to be expensive, just like testing all possible uses/states of a bridge would be expensive.
There are things that can be done to isolate and reduce the number of possible faults, but they are not the same things that you do when building bridges.
The key point is being in the same group than your boss...
Wait.... it can be done? No Way! My point holds for anyone who uses MySQL-specific, Oracle-specific, or whatever "dialect" of SQL. Don't blame SQL when someone asks you if you can port to a different dB and you can't.
My turnips listen for the soft cry of your love
You see, odds on, they _designed_ it correctly, it met with testing, etc. but when the release process came out the disc had slightly corrupted binaries from off of a flawed mastering run to CD- and no checkpointing on the install to make sure that the code was good.
In your case, they probably didn't initially know the batch of materials they were using was defective.
In my analogy, this is more they shipped KNOWING that the keyhole had that vulnerability, hoping nobody would spot it. I can assure you that some of the flaws out thee in Windows are of that variety. There can be no other explanation for it.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I tend to assume the person talking is very young or extremely ignorant when I hear that kind of stuff...
Once more people realize that they do not have to agree and demand different, things will change. Or, appropriate state and local gvnts may want to require certain software products to be sold only if its maker assumes liability.
The world's six billion people can be divided into two groups: group one, who know why every good car 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 car company would ship a product before every last bug is fixed. Every time GM releases a version of Cadillac, 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 product developer, you need to get into group one, where I am.
Seriously, this is true for almost any business sector with complex products.
First enbugging (typing, coding, a.k.a. putting bugs into code), then debugging (finding them to take them out).
Perfectly circular, like Yin and Yang.
Since the action of coding the bugfixes falls on to the enbugging side, there is a strong possibility of achieving perpetual programming :-)
Job security... of a sort.
When I worked at then Unisys Airline Center in the early 1990's, the defect count for the product we were working on had to be down in the single digits before a new version of the product was released, ...
Those of us with a bit of experience recognize this as having one primary effect: Employees are strongly discouraged from reporting bugs.
I've worked on any number of projects where my immediate boss would make it abundantly clear that we keep our own private lists of "issues", and only add something to the official bug list when we have implemented a fix.
If you want to know about bugs, you'd better make damned sure that there is no punishment for reporting a bug.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
1) All software has bugs. ALL SOFTWARE!
If you think your software is bug free then either:
a) You are clueless, hopelessly naive and inexperienced.
You may not even know what a bug is. Bugs range from cosmetic bugs such as mispellings in text labels, or the wrong color for a panel, to a bug that causes data corruption or system failure - but they are all bugs - including not meeting the user's expectation of how something should work.
Moreover, almost all software uses third party libs or application modules - ranging from the operating system (and all of its modules), to system libs to language libs, to special purpose libs (such as XML parsers, etc.) that you have little to no control over and certainly don't have the time to test or examine. You just take it on faith that these do not have bugs - but they do. If they are part of your application or you have not found and worked around these bugs, then your app has a bug - and if you think every OS and third party lib is bug free then I have to wonder what planet, nay what universe you are from.
or
b) You (or a designated party) have not tested your software properly.
Most developers are clueless when it comes to testing, and even if they had a clue (like me - I am a developer, but I spent almost 8 years professionally testing mission critical apps, including medical software) the developer is not the best person to test their own software - that job is best done by a professional and experienced tester who has not written the software - preferably someone who has not tested your software before.
2) There is no way to completely test any software application - no matter how simple - you can't even approach it, or even *begin* to approach complete testing of software. Even automation can not test every possible data input with every possible logic path. There just isn't enough time:
Testing a very simple program which just adds two 32 bit integers can take years - assuming you covered just the possible data inputs, and assuming you limited the input to integer numbers, not to mention alpha chars and floats - do the math (at 1 billion inputs per second [an extremely optimistic assumption], it would take over 500 years to test all possible inputs of adding two 32 bit integers).
That is just the possible integer inputs, not every possible logic path for every possible data input - and that is about as trivial a program as you could possibly make.
Most testing concentrates around previously known conditions which caused previous bugs (to make sure they don't resurface) and around other inputs/conditions/scenarios which are most likely to find a bug. The art of Software QA/testing is not to prove that there are no bugs, but to find the bugs that we know are there in all software - with priority given to "serious" bugs (what is "serious" depends on the context).
3) The severity or risk of any given bug is highly subjective and contextual. In some contexts a program that crashes routinely is preferable to a program that gives the wrong answer. In other contexts the reverse is true. In some programs (minesweeper?), either crashing or wrong answers doesn't mean a whole lot except that the user may go on to some other program.
Saying that Windows has thousands of bugs doesn't mean a whole lot until you start categorizing the bugs and analyzing the risk vs. benefit of the bug vs. the OS - and that depends a lot on the intended use.
If you don't want to use software that has bugs, better get out the pencil and paper.
The job of developers, QA staff and project managers is to weigh all of these factors and to do the best job we can given the human resources, time and money we have. No software is ever perfect or ever will be. Deal with it.
Organizations which adopt a process oriented approach to software development have a far greater chance at succeeding than those which do not.
Enterprise frameworks such as ITIL and COBIT, coupled with software development lifecycles such as UP and Agile/XP increase efficiency, improve quality, reduce bugs, and help align deliverables with customer requests and expectations.
Development outside of mature process frameworks is by its very nature ad-hoc; if you have excellent people who are the best in their industry, you can sometimes get away with running your development shop this way; generally, though, projects fail, code is shipped with a high number of bugs, quality is severly impacted, and your customers, clients, or business partners will be disappointed.
"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?"
This *used* to be the norm for software, but MS had a big hand in getting rid of this, and SQL Server was the worst offender. MS always viewed a bug list as their admitting a weakness.
Let me tell you a true story.
Back when MS put out SQL Server 6.0, it was basically a rehash of 4.2, but with a nicer GUI. It was a big step forward for usability, over the old OS/2 version. What we discovered was that there were certain things that would corrupt the data, but looking in on Compuserve (the web wasn't big yet) or on MS's BBS didn't yield any listings of problems or bugs. So we called MS, and after signing an NDA, they showed us tools that would potentially fix the corruption. However, they would not tell us why the corruption occured. They simply would remain silent. I asked them for their bug list (every software vendor that I knew of had a bug list, especially something as complex as a DBMS), and they said there was no such thing. Of course there was such a thing. Every vendor had to have one, because otherwise, they could prioritize their patches. What they meant was they wouldn't admit to a bug. How could you run a mission critical system without a bug list?
Well, the next week, the MS Salesman showed up, I vented frustration on the issues. I said "Why don't you publish a list of known bugs so we could at least work around them".
He replied "If there is no bug list, then there are probably no known bugs".
I gave him an icy stare (I was doing 18 hour days to fix the problem), and I said "Mike, if you're telling me SQL Server has no bugs, you're either a liar or an idiot. Which best describes you?".
He got pissed off and left and didn't come back for about 2 months. We never got along very well after that, and to this day, I put that down as the day I strated to become disillusioned with MS's products.
THE LAST BUG
"But you're out of your mind," They said with a shrug. "The customer's happy;What's one little bug?"
But he was determined. The others went home. He spread out the program, Deserted, alone.
The cleaning men came, The whole room was cluttered With memory-dumps, punch cards. "I'm close," he muttered.
The mumbling got louder, Simple deduction, "I've got it, it's right, Just change one instruction."
It still wasn't perfect, As year followed year, And strangers would comment, "Is that guy still here?"
He died at the console, Of hunger and thirst. Next day he was buried, Face down, nine-edge first.
And the last bug in sight, An ant passing by, Saluted his tombstone, And whispered, "Nice try."
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Following the GNU arguement, if you're running GNU and KDE on top of open source APIs under Windows, aren't you running an open source operating system on top of a closed source kernel?
It's been a long time.
Very true, and there's a good reason for that: Boeing et al. recoup every penny of their software development costs, because it's built into the selling price of the 747. There's no point in pirating 747 software, 'cause what are you going to do with the software if you don't have a 747? (Ignore the terrorist scenario).
If there were some way of eliminating 'piracy', and guaranteeing that the developer gets every penny of every copy used, you would see quality go up. Not everybody can afford a Porsche (substitute brand of your choice), and yet Porsche continues to make & sell superior cars. That's because there will always be people who appreciate and are willing to pay for quality in a car. And you can't replicate cars for free the way you can duplicate a CD (not yet anyway).
There will always be a market for the software equivalent of a Hyundai, and people willing to settle for lower quality. But if you could somehow protect sales, there would also be a small but lucrative market for people who require, and appreciate, quality in software. Kind of like Apple. (No, I don't use an Apple computer. Just an iPod).
You disagree? Please tell me what OS, development platform you use, and which flawless products your company produces.
Slashdot entertains. Windows pays the mortgage.
I've worked for a few companies that have shipped software to paying customers. The secret to shipping with no serious bugs is reclassifying them as less serious before the ship date.
Having been both a programmer and a test drone, I can't believe that anyone would think any code ships without known bugs. I guess not doing testing would be a good way to achieve that honestly.
First of all: cat has no know bugs. grep has no known bugs. It is possible to develop software with few or no known bugs at all, it just takes longer -- and "fixing" a bug by not introducing it will not introduce more bugs.
Second: Look at severity. IGNORE frequency. If 2% of the users of a filesystem experienced corruption (or even imagined corruption, hardware problems, etc), then the filesystem and the company gets a bad rep. Look at Reiser -- ReiserFS v3 is rock-solid now, but it still takes the blame for bugs that weren't even in the product itself.
In other words, if your software works fine for 99% of people and causes catastrophic data loss for 1% of them, that's far, FAR worse a bug than a bug which causes slight annoyance (discoloring of a single pixel) for 100% of users.
This guy is merely trying to justify his product being shitty and MS-centric, and in the process, he's defending MS and every other lazy dev shop out there.
Yes, do have a list of known bugs. But don't avoid fixing them because they're minor, or because they only affect 1% of your users. And if you can avoid bugs, and if you can show that you fix bugs quickly and don't introduce too many more (statistics run on your bug-tracking system) -- I think that's a far more valuable image to project than an image of getting software out the door quickly, especially because most people don't care about development time, they care about the quality of the software that they get out of it.
Don't thank God, thank a doctor!
A small bug list can just indicate poor testing or poor reporting. While you don't want major bugs to be in the bug list in high numbers, a bug list should contain all of the minor quibbles that cropped up during extensive testing.
A small bug list proves very little.
We used to hold our products for two weeks at a bug count of zero. Any new bug would reset the count. Then we staffed up our QA team. This practice became impossible. Our known bug list went from zero bugs to hundreds deferred in the next version, but our quality improved.
"...But if you are a software developer, you need to get into group one, where I am."
Who's in group one?
I dunno.
No, he's on second.
Who?
No.
What are we talking about?
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.)
If it is a couple of "small, esoteric display bugs" that they already know about, and they are not related to a hardware issue, then give me one good reason why they shouldn't fix them before rolling out their software?
The reason they would roll it out is because they do not care about the quality of their product. They just want to make a quick buck.
The size of the project itself is irrelevant - as I mentioned, it is just sloppy development techniques that result in unmanageable software.
probably not strict and technically, no you are not, but I see the point and for conversational puprposes I will agree in the general way.
I think it's a bad idea long range and a severe waste of resources and time and effort, all to go to still keep MS on top and rolling in the dough to amazing and near obscene levels, while a lot of the open source devs say they can't make any money at it.
It should be obvious by now doing ANYTHING to make closed source better by using open source to "enhance" it is shooting yourself slowly in the foot, over and over again and then wondering why you stay crippled up and hobbling.
BANG why am I limping?? BANG why am I still limping?
It's nuts.
Open/closed are two completely different philosphies and business models and as such, if you keep trying to blend them you will keep running into weird problems and keep trying to play "catch-up" all the time while the fatcat software overlords fly around in their business jets laughing at you for doing their work for them.
MS is play acting at being against a lot of the efforts, FF on windows was and continues to be a godsend to them, it gave them YEARS worth of breathing room so that windows users could keep using the net even half ass securely, wheras IF the only viable alternative would have been a complete switch, it just might have made a lot of them look at it closer.
I'll repeat the challenge, I'd like any open source devs who work on windows apps like FF for windows, in the hopes that someday people will switch to all open source operating systems PROVE that this is happening beyond less than the margin of error at one percent. Let's some some verifiable prrof that this idea is working.
I am not seeing any mass switching anyplace, just people staying stuck on MS windows, albeit some ludicrous small number now might be running a few open source desktop apps, and even there it hit a plateau at maybe 10% then leveled off.
Not seeing any hardware vendors cooperating beyond a complete joke level, not seeing any significant stores offering a wide selection with new installs, not seeing anyone out in meat space who games switching, nada, zilch.(we will stick with US region for this right now, still the largest market in ther world)
The adoption of open source operating systems is still at the same level it was several years ago, 1 or 2 percent tops,even though they are a LOT better and you certainly can't argue with the price, and I maintain it is *precisely* from open source devs doing their thing for the windows platform thinking their efforts will be some fantastic "switch" lead in, to "ease" the users into it. False premise, not born out in the real world, just look around. I appreciate the effort and interest, but I think it is naieve now to keep insisting it will "work" somehow, else we would be seeing the evidence of it. The only switch I have seen is a few more people (statisitaclly percentage-wise) going to OSX, and that has pulled about equally from the linux and windows camps so it's a neat-even wash there.
It's a war,for long term hearts and minds and for the adoption of what a lot of us see as the far better way for everyone on the planet to get better code and for businesses all over to be able to use better code to make more money ion the real business of the world, which is anything BUT software. software is just used to do OTHER business, that's where the REAL long term money comes from coding and admining and such.
And until people can see and act like it is a war, and see how to use open source to make your real work better, appeasement and collaboration are not going to work and will keep it at an "also ran" level.
IIRC VMS reached the point where after some period IBM did an analysis and discovered they were creating 1.1 new bugs for every one they fixed. At that point they stopped fixing bugs (if they were around by then they were minor) and just started documenting the heck out of them.
This was not a trigger for a total rewrite. It was a good thing. The system was finally stable (on that hardware). Sure it was obsolete, so what?
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Isn't that part of Microsoft's business model?
They wouldn't fix them because the potential knock-on effects from changing the code-base at a late point in the development cycle massively outweigh any potential benefit that the business places on the fix.
In reality list of new features combined with bug fixes is handed to the business. The business decide how much they want to pay for development and when they want their next release to be. The developer pool size is known, and therefore the man-hours available is also known. Estimates on time taken per feature/bug are supplied by development to the business, and the business then prioritises exactly what they want in the new release. The reality of the matter is that the business will ALWAYS choose the new features that are going to make or save them millions over fixing the small bugs that they understand and know how to work around.
There's no sneakily fixing those bugs on the side either. All code changes have to be checked in against deliverable items previously agreed in the business scope. Business deliverables are the priority, and off-scope changes introduce unmanaged development risk into the project. It's just the reality of the situation.
The gift of death metal does not smile on the good looking.
On the web, you can ship a new build every day (if not oftener). CD's or DVD's in boxes, trucked to stores are a waste of time, energy, oil, and trees.
The problem with software is with the software market. You only know whether you like it after you buy it, and if you don't like it, tough.
I went to one store to buy a web cam, and when it didn't do what I wanted it to, I returned it and got another webcam from a different store.
If I buy an OS (or any other software) from a store and it bugs me, then I try to return it, they would laugh at me for trying to return opened software. If I want to buy or use other software, then not only will I have wasted my time and money on the first program, but I will have to spend more time and/or money on installing and learning a new one.
From the vendor's point of view, they've already made the money off of me, and they're not giving it back. The next version is different or "better", and after waiting 5-7 years (:P) customers will have forgotten how frustrated they got the last time. Since closed-source software companies tend to not release bug data, it's really a gamble when I purchase the software in the first place as to whether I would be satisfied.
- RG>
Hey pal, this isn't a pleasantforest, so don't waste my time with pleasantries!
I hope you are still honoring the memories of the firefighters who died after they reported over the radio hearing a series of explosions that collapsed the towers. The same with the maintenance worker pulled from the rubble who said the same thing, the people who's testimony was NOT in the kean whitewash report and the recordings of them NOT released to the public. The firefighters who croaked in WTC 7 after reporting that they had the fires blocked and were in clean up mode them BAM BAM BAM BAM.
I hope you take it as serious as millions of other people do who can see quite clearly that this current government-some cabal of insiders in extremely highcommand levels- allowed this thing to go down for profit of various kinds. The people who were running a "drill" that day with "airplanes used as weapons" that they later claimed they had "no knowledge" of anything like that even contemplated. The same cabal that clearly had all the project bojinka information. The same cabal who issued warnings to selected politicians to not fly that day. The same cabal who ignored warning after warning from some foreign intelligence services, and who conversely don't think it is relevant that ONE of those services notified nationals who were there who failed to show for work that day and escaped the fate that others had to endure. The same cabal who refused to let david schippers of past presidential impeachment legal fame and credentials issue his warning of imminent upcoming terr attacks to them, in JULY. The same people who ordered various control tower tapes of airliner captains transmissions to be destroyed, the cassettes crumbled and placed in separate waste receptacles and ATC guys to SIT DOWN AND SHUT UP. The same cabal that ordered various of their lower level federal cops to STOP INVESTIGATING what looked like an upcoming terror attack once they saw it went upstream and started WHITE GUYS WITH BLACK SUITS AND FUNNY SUITS WITH BRAID AND RIBBONS. The same fed cops still sitting in limbo to this day and never yet with their day in court for some rather mysterious reason.
And so on, there's a HUGE list out there of strange and oddly weird "intelligence failures", which looked at from a more realistic point of view, look suspiciously like intelligence successes, as in "mission accomplished", the grand "pearl harbor" event excuse to go apeshit in the middle east and institute domestic big brother actions to an unprecedented level not matched since the Civil War..
I sincerely hope you are honoring your friend's memories by not swallowing the governments ludicrous fairy tail conspiracy THEORY about what really went down that day and who was responsible for it. It was the culmination of a long running slow speed coup d'etat, and it had very little to do with some ex-CIA asset wearing a bathrobe hanging around in a cave someplace.
Yep, it was a conspiracy,and the governments public version is so full of holes moths wouldn't even look at it, not enough to chew on.
So you're saying I am paying Microsoft for a license to get the priviledge of beta-testing their software? *shock*
It is possible to give the same sort of assurances for software by using similar engineering techniques.
Please enlighten myself and all of the math and computer science researchers that have been attemting to solve the problem of correctness. What specifically can be done to ensure correctness of algorithm, and correctness of tens/hundreds of thousands of algorithms working in conjunction. What physical engineering techniques apply?
I don't disagree that it is a worthwhile goal to create bug-free software, and I think that with proper languages/tools/etc. progress can be made, but if you think the answer will come from the physical engineering disciplines then I don't think you have studied the problem.
Not quite. There is a third and much larger group with vastly more pressing issues to deal with, who couldn't care less.
Well, if buggy cold wasn't sold or distributed then we wouldn't have any software.
The last 10% of a project takes 90% of the time. ...
The last 1% of a project takes 99% of the time.
The last 0.1% of a project takes 99.9% of the time.
So, at some point you just ship it.
Otherwise, Joe Sixpack will always buy the product that does not tell him about the known bugs. "Gee, Mable, the Microsoft version has 1000 bugs listed, but the Happy Lucky Kitty version doesn't have any bug list at all. I guess we better buy the one with no bugs!" The first company that advertises its bugs probably goes out of business or has a stockholder revolt leading to new management.
I don't know about you, but I'd be much happier with a purchased product that had a bug list, perhaps with suggested workarounds, and an estimated timetable for fixes if a fix will be forthcoming. (And if none will be forthcoming, I know to look into the workarounds.)
I mean, people NOTICE bugs by the consequences, so it's not like you can hide them. People just don't know how to deal with the bugs they get, and sometimes aren't exactly sure what triggered them. Something as simple as the presence of a page that says "Pressing button C, B, and then A causes a crash. We're still trying to figure out why," would tell me to not press the buttons in that order until they fix it.
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
I'm in group one and I'm still shocked by just the sheer absolute volume of bugs released in some things. For example, Oblivion. They just rush things out the door too much more these days. I understand you have to get things out in time to meet deadlines, but, it's starting to become ridiculous. The scary thing is that more and more often I'm seeing bugs (particularly in games) which should have been caught in the initial-most testing stages, long before they even got to the REAL QA... For example, I mentioned Oblivion. Clearly they never bothered to even test that game on a system with a nvidia video card. Actually, my impression after further playing and visiting of their tech support forums is that they really didn't test PC much at all (it's an XBox360 game that we're just lucky enough that, oh yay, they decided to port to PC while they were at it just to be nice.) The fact is, with a lot of newer stuff I've had a growing suspicion that the teams are getting lazier and lazier with each new release.
Ironically, MS may actually have gone down rather than up. Seems like Windows XP crashed a lot less than, for example, Windows 2000 (which didn't get along with a lot of hardware so crashed a LOT.) I wish they'd get their bug control to catch up already though. They MIGHT be getting better, but, they have a long way to go to catch up to, for example, several of the major linux distros.
In your sig you said: "There is nothing inherently safe about liberty. That's why so many people died protecting it."
Tense fault. It should read "That's why so many people DIE protecting it."
The process is ongoing. Live for it. Die for it.
A pessimist/historian might opt for the perfective form: "have died", implying that such death has gone out of fashion.
y your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.
well, I am not a Civil Engineer. But I would venture to say that it is the job of a Marketing Engineer (I use the term Engineer loosely) to specify the lifetime of the aformentioned bridge to be limited to a timeframe that elapses before the bridge would collapse.
Thus, no bridge collapses during its specified lifetime.
Has anyone mentioned that if you try to burn out every bug the product will never be released, let alone not released on schedule? The article seems to have completely ignored this point, which makes me think it went through a heavy round of review by his corporate management. Timeline is the primary driver on every final bug list I have ever worked on. Sag.