>John,
>
>>Hi Jim,
>>
>>>I really am always amazed when software errors are so wilfully tolerated when errors in virtually any other kind product are definitely not tolerated. My guess is that it is us, the developers, who are the primary proponents for this stand and it likely has much to do with our own needs to have ass-cover for our own problems.
>>
>>Surely you have evidence that the errors which precipitated our quick fix were willfully tolerated? I don't like the implication that we know of major bugs when the product is released and release it anyway. It's just not true.
>>
>>There is no such thing as the zero-bug piece of software. Some bugs are just easier to find than others.
>
>Either you misunderstood or I was unclear.
>
>I was referring to those who said 'all software is going to have errors' and not only wilfully accept that but also appear to use that as justification for the delivery of their own buggy applications too.
>
>I think, in the prior paragraphs of this specific reply of mine, I was quite fair and sympathetic of MS' general circumstances for its development/testing difficulties. I have no idea how you connected anything I wrote with even a hint that the VFP Team knew in advance of the (now known) bugs.
>
>But to answer your point directly:
>Do I think for even a second that MS or the VFP Team wilfully deliver a product with known bugs in it?. . . definitely not.
>
>Do I think it is possible to produce zero-bug software? Yes, I do, and yes, I feel that MS is (at least since W2K was well under way) working toward that objective.
>
>You see, even though many cars are produced with defects, it is a fact that many more cars are produced that function perfectly properly for their users throughout their useful life. With cars, every one is a new production and yet they can do it repeatedly. With software, every one after the final is an exact replica of the final. And I truly think that the design/development/production of a car is at least as complex as the design/development/production of any piece of software. Because all of the complexity of a piece of software is concentrated in a single place it just looks far more complicated. Think about how many lines of code are likely used to design a car (and each of its parts) and its production and test facilities and then add to that the actual building of the machinery needed to design, test and produce the parts for the car and add to that the coordination to actually have the parts at the right place at the right time to build that car.
>
>JimN

Jim;

It seems hard for some to understand what you and I have been saying. My thoughts may be a bit different than yours but I think we are on the same track. Interesting how people twist what we say for his/her own purpose. I am not referring to one person but many.

I mentioned quality should some how be introduced into the software process differently than it is at this time. There are many different ways to approach the subject but no attempt to standardize the approach. Which approach is best and why?

I made the analogy of automobile quality (specifically Toyota, the industry leader) and software. Why? Because Deming introduced quality into Japanese manufacturing. Americans had and have the attitude – we don’t need any stinking quality. We accept crap and that is our fault.

When market share in the automobile industry occurred for American cars and Japanese cars were becoming popular some American car manufacturers began to look into the Japanese process (invented by Deming – an American). This spread to all areas of manufacturing – electronic – etc. The Japanese took over electronic manufacturing and put a lot of Americans out of work. In 1969 52% of all cars sold in the United States were Chevrolet. On average a car had to be tuned up every 3000 – 6000 miles and the engine wore out at about 70,000 – 100,000 miles. Remember the term “Designed for Obsolescence”? Today cars require a tune up at 100,000 miles and keep running. My Volvo has over 340,000 miles on it and runs fine.

Now granted making a car does not require millions of lines of code like an operating system. I bet we have about a million lines though. We have 80 programmers and 56 servers, SQL Server and Oracle backends, and many programs we have written just to run the process.

Forget the process. How about the thousands of people whose brain power is required to make it happen? Making a car that has quality is a real team effort and takes everyone’s attention – on three shifts. We are a company that believes in quality. I see no reason for the software industry to continue with an attitude of “ship it” with known bugs. Each minute of down time costs this company $10,000. We cannot wait for a hot fix – it better work the first time and we test the hell out of it before going into production.

Yes software will always have bugs to some degree. Sometimes it is simply an incompatibility with other hardware/software. No software written can take into account every piece of hardware and software combination possible. Bugs come in many forms and I know we agree Microsoft did not knowingly allow these problems to be released. A mistake occurred in the process somewhere along the line.

As I stated previously I hope that the seven issues are not released with the retail version. Stating you have seven known issues before you go retail does not look good. Great – the seven issues were found quickly but why did this occur? Trying to convince IT decision makers to use Visual FoxPro is hard enough without this type of occurrence.

So my interest is in the process and approach to software quality. We should not have to accept the “fact” that all software has bugs. The reason software has bugs is because of human failure. Some software developers accept that and roll over and play dead. I think the software industry has growen up to the point where it should show credibility to itself, developers and customers.

Tom