Jim,

I'm curious. Do you report all of your bugs to your clients? I don't. However, when they report them to me (the ones I don't find <g>) I fix them; but I don't always get them right back out to the clients for delivery/scheduling reasons.

Isn't that what Microsoft is doing and isn't that what we all do, including you and Steve?

I'm just afraid that as a direct result of what appears to be a need for folks to 'win' this discussion that we've all kind of lost our perspective. No one being 'right' or 'wrong' but attempting to take what is essentially the process of software development and turning it into some sort of absolute.

I don't know about you or anyone else but one of my biggest headaches is dealing with one individual in our organization who is simply unable to see that software development is a process. He always wants "bottom line" answers and I can't always give them. As such I suspect he sees me as somehow trying to deceive him when that's the last thing I want to do. I see him as unwilling to look at the facts simply because it will cause him to step outside of his bottom-line mentality.

I'm sure we've all dealt with these kinds of individuals.

My users certainly get frustrated when bugs show up, that's for sure. In my case I'm dealing with eleven years of legacy code, written by about 20 different programmers, none of which it seems knew anything whatsoever about commenting code <g> (with a few minor exceptions). We have some 2500 people using the product in various releases, almost all of which were not tested before delivery. What I am doing is personally or having my staff fix them as fast as is possible (I call this the triage phase <g>) so we can generally stabilize the product enough (we're there now) so I can go back and totally re-engineer the product from the ground up - this time creating documentation. Even so we still get errors. 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.

So, I know about the struggles first hand and this seems to make me more appreciative of the efforts of Microsoft and I guess you as well are taking. I don't really know what kind of software you write or whether you write vertical market apps or what you have done but I'm sure it's comparable. What or whom do you develop software for? What industries? I seem to recall that you've been doing this for a long long time though. Have you always been a code jockey or management or both?

Regardless, I keep coming back to this notion that we do not live in the kind of world where everything is always the way it ought to be and I think that sometimes we make ourselves more frustrated because of the internal conflict between our desires for a perfect world and the reality that this isn't it. <s>

I think somewhere here is an acceptable tradeoff between the two points of view.

What justifies all the fuss??





>Well isn't that special.
>
>Now we have an esteemed MVP essentially saying that the 75+ bugs reported here for VFP7 are essentially a product of poor developer practises and/or poor quality operating environments.
>
>Even if they were (which you most assuredly know is not the case) MS elected to sell VFP to the masses and they, more than anyone else, know precisely what that entails in terms of potential support issues. Non-programmers will buy it and it will be run on antiquated gear with old and unmaintained OSes and old drivers and faulty peripherals.
>
>Reminds me of another who stated that VFP7 was essentially C000005-free. Then SP1 came out, fixing several.
>
>And in any case, why does this qualify current bug reporting/publication practises as acceptable in any way???
>
>You guys need to be more in touch with "the community".
>
>
>>Me too. My mean time between VFP errors is measured in weeks, if not months. Not to say problems don't exist, but the combination of good hardware, good OS (NT 4+latest SP or Win 2K), and not trusting most ActiveX controls from any source means virtually zero problems.
>>
>>**--** Steve
>>
>>
>>>Really? Wow. I don't remember the last time I had problems in VFP (and I use it everyday, all day) that I lost time or work due to a FoxPro bug.
>>>
>>>And I do a lot of stupid stuff with VFP. If anything, I get a C5 here or there and testing, then I find someway to take care of it.