Hi Marc,


>> Untill I can get our software refactored into something that at least resembles a product that has actually been engineered I have to live with what I have. Remember, inside of Visual FoxPro 7.0 is FoxPro 6.0, 5.0, 3.0, 2.5a, 2.5, 2.0, FoxBase + 2.10, FoxBase 2.0 and FoxBase 1.0
>>code. The operating environment that this product has had to work with is quite wide and varied. I think that the developers have done a great job being able to both move the product forward for the some eighteen years of its existence with as few problems as they do indeed have. I cannot in my mind justify criticizing them in as harsh a fashion as I've seen some do. Now, Microsoft itself may,as a result of their corporate policies be adding to the troubles rather than reducing them but as far as I can see they've pretty much let the FoxPro developers have their way with developing the product and I will absolutely assert that we have a far better product now than Clipper or dBASE, our old competitors. Where are they these days in the great scheme of things? We're still here, being developed (VFP 8 is on the way, remember?) with at least a good ten years of time to keep plying our skills. Will we always be in the forefront? Nope, not even now though VFP can do some things other
>>products can only dream about.
>>
>>
>>What justifies all the fuss??
>>
>"Microsoft Corporate Policies" that make that talented developers like yourself accept that your products are not be at the levels of QA that any other industry would consider minimal. Would it be acceptable that GM would not report a small bug, a screw that's loose, because they do not have the time to maintain a customer support system or because car dealers are sloppy when they report loose screws?
>
>"Microsoft Corporate Policies" that are the cause that VFP is probably better than it used to be, but not nearly as good as it could have been if reasonably professional criteria of Quality Assurance had been the norm at Microsoft during the last 15 years and probably more importantly, if the real potential of the product had been recognized.
>
>People like Jim who do not accept this situation, although like the rest of us, he could work around most of the bugs.
>
>My 2 Euro cents of dead horse...
>
>Marc

Well, look.. When you figure out how to convince a company that has been successful enough in the marketplace to bank some 40 billions of dollars that their policies need to change please let me know. <g>

As for the rest see my reply to Jim.

Thank you for the kind words but please do not think that I do not want to move forward. In my thinking process it's more a matter of how one influences change. I have come to the conclusion that if I am able to create the world class product I think I am able, no.. that I know that I am able to create, then I will have the attention of the kinds of people at Microsoft that I need to have in order to really make some changes. Same goal, different strategy....

As far as my products' level of quality, I can assure you that they will be as high as is humanly possible. They are not there now but I intend for that to change. Funy thing though is that I'm finding that it tales a lot of time and effort - probably something like the VFP development team and all the rest of the developers at Microsoft.

Does anyone reading this honestly think that the developers of the several Microsoft products want so ship buggy software??? Or that they do not want to fix said bugs as quickly s is humanly possible? Does anyone think that the developers at MSFT don't get frustrated when they are told that there's no ROI benefit on fixing some obscure bugs? How would you feel if someone told you that you needed to leave those few bugs in your software because it needed to ship? I wouldn't like it one bit but I'm not a businessman who's responsible for the jobs of the other 40,000 employees; I'm a developer who likes to think he can write good code and more than likely a lousy businessman. <s> Sad to say but there really are reasons for these things...