Mike,

The "standard" that I was referring to was as regards bug reporting.
When FP was Fox Software we were able to learn of every known bug.
WordPerfect set the standard (admittedly expensive, but I do wonder where the PC business would be today without it back then) for customer support. It is likely to me that their seeing MS get away with far less promptd changes on their part.

As regards flawless software delivery itself, my problem is widening customer acceptance of the phenonemon and the subsequent corrosive effects on the quality of software delivered as a result.
Using excuses like a recent customer purchased on the basis of a new version delivery on date certain is really poor in the general case.
First, that represents only a small handful of customers, possibly only one.
Secondly, how were existing customers allowed to register their requirement/preference on the issue. Long-standing customers should be viewed as far more valuable than recent or potential customers.
Third, it can only result in more trouble and added support costs, not to mention existing customer dissatisfaction.
There are, of course, more reasons why it's a bad idea.

Good management can ensure that delivery schedules include adequate Q/A and good management will judge if published delivery dates should slip in order to protect their reputations.

dBASE IV showed clearly what can happen when pressure to deliver is allowed to win over reasonable quality. Sure they had promised too much and had already deferred the delivery a few times. But in the end they succumbed and look at what they reaped!

Note, by the way, that we have not yet been apprised of a delivery date for VFP. That's fine by me, and I fully expect that when we do get one that it will incorporate sufficient time to deliver as clean a product as possible.

I don't have a problem with some qualified senior management making a considered decision at some point to deliver. This would be after assessment of potential known bug impacts and their effect on existing customers.
But the concept of a very restricted beta to keep bug counts down is a serious problem!!! At best you are just faking a beta, going through the motions so that you can say you did. Thsi serves neither the customer nor the company.

cheers


>>> MS has set the standard that other companies are more than happy to follow because MS severely LOWERED IT. <<
>
>While I agree with you that it would be nice if software were not released with known bugs in it, that simply is not the way the software business works. And the practice certainly wasn't started by Microsoft. Even companies with far lower profiles than Microsoft have practical considerations associated with release dates. Customers have been told the software will be available at some point in time. Often they have already bought the software or upgrade based on that date estimate. You can't sell software on the basis of "you'll get it just as soon as our Q/A group says all the bugs are out, whenever that happens to be." It. Don't. Work. That. Way. Again, this is not a Microsoft phenomonom or one started by Microsoft. I worked for a software house for 10 years and we did it exactly the same way. Not because we didn't care about getting the bugs out but because the development group did not work in a vacuum. We had sales, shipping, and accounting considerations. And we
>didn't even have to worry about some of the date-driven things Microsoft does -- launch events, ship dates to resellers (who have catalogs and whatnot to get out), timed "leaks" to the press, etc. The release date drives everything. You get out as many bugs as you can by the ship date, that's all. Everything after that is a service pack.
>
>Not ideal, and not the way many of us on the development side would like it to work, but these are the facts of life in the packaged software business.
>
>Mike