>> I see no reason for the software industry to continue with an attitude of “ship it” with known bugs.
>
>Even when the bugs will never show up in a production environment? There are known bugs in VFP that I can guarantee you'll never find. I can crash VFP7 in three lines of code, but I'll bet you never will be able to. But I can also crash my microwave and my cell phone (still working on crashing my DVD player). I'm a tester, it is my profession. I'll find stuff that no other user is likely to find.
>
>So do we spend resources to fix something that only a pathological tester can reproduce? No, the risk is too great. For every bug you fix, there's a 60% chance you'll introduce new bugs. Open 100 projects in the VFP IDE, close VFP and fire it up again. Oops, all 100 projects didn't open again. Do you fix that at the risk of introducing new, perhaps more evil bugs? I think not. Nobody in their right mind is going to open 100 projects at once. No customer has ever reported it, and I'm the first tester to find it, and then only by digging through the source code. So why risk introducing bugs that users will find?
>
>Any test team, whether Microsoft or not, will allow a product to go out the door with known bugs because it's a trade-off between the risk of fixing the bugs vs. the odds that a user will run into it. If a product team fixed every bug that that a competent test team found, any reasonable complex piece of software would never ship. We wouldn't have microwaves or cell phones, either. :-)

Mike;

From a practical standpoint you are correct. If you had read all my posts on this you would realize I mentioned release of a product is a management decision. I have worked with several groups on software development during the last 19 years. My comments are not directed at Microsoft but the software industry as a whole.

During the last ten years as an example I have seen a number of interesting software related events. The term "First to Market" was a battle cry for a long time by many companies. That meant even if you had a showstopper - you shipped! Again a management decision.

It is impossible to provide bug free code at this time. I have seen a program run for six months 24/7 and then break. No change to the hardware/software environment had been made. This was Visual FoxPro and I have seen it more than once. In one case the programmer put code in a Valid to SetFocus(). It should not have run but was code in a child object that did not know this - until one day it quit working! I term this a "soft failure" - one that should have occurred before an exe was created. Software can be fun! If you follow the rules you will have greater success.

I like to write code and test! Breaking code is something I am very good at so other developers like to give his/her application to me for the once over before shipping to SQA. The big joke some developers liked was when a client would call with a complaint due to software failure. The developer would say ”what did you do”? The user would respond and the developer would come back with “You should never hit that combination of keys”! Why do some people dislike some developers!

Tom