Alan,
How do you know the end user, in this case you, is not part of the equation?

For any given user community of some size, there needs to be representatives. The entire user community can not be (and should not be) consulted for each thing. Your representatives are "bug reports" with detailed explanations and reproductions. They are user group leaders. They are MVPs. These entities have MS's ear. Except for bug reports, they represent something larger than themselves.

WRT the time wrestling with bugs, I'm not sure I understand. If you come across a situation that you think is a bug, do you search the KB articles to determine if its a known issue?

If you find it, is there a work around posted? If so, what's the problem?
If you find it and there is no work around posted then either one isn't known or one is known and it hasn't made it through the review process to get the article updated. If you create a work around in the interim, submit it as part of the bug report. If a work around wasn't known before, maybe you can help others with this problem in the future.
If you don't find it, then its either unknown to this point or the article hasn't been processed yet. Submit it.

I happen to think the end user in in the equation. It may not be to the extent that each and every end user would like, but that's normal when you're dealing with a large group.

Regards.

>I sort of agree, but not entirely. The problem is that the end user (developer in the case of devel tools) is not part of the equation. If there are known bugs, and known workarounds, and there must be for priorities to based on them, then that information should ship with the product. As far as I can tell, it does not, and subsequently our time is wasted when we run into those issues. The idea that MS's (for example) time is too valuable to waste on low priority bugs, but that the time I have to spend wrestling with them when I hit them is worth nothing, is an issue as far as I'm concerned.
>
>I have to wonder - cumulatively, how much more or less time is wasted by all of the end user developers on those bugs in relation to the time that might have been 'wasted' by the software producer in fixing the bugs.
>
>I think that if the end user ever becomes part of the equation, we'll all be a lot happier.
>
>Alan
>
>>Gerry,
>>I believe the opinion is shared by more than one person on one product.
>>
>>IMO, it's really all about priority. Yes there are bugs that have been left over for years. However, it sounds like there are also work arounds for those bugs that have existed for almost as long. If there is a "relatively straight-forward" work around, then the priority drops. It's that simple.
>>
>>In a utopian society, we could fix all the bugs found and also implement all the enhancements wanted. This isn't Utopia. Priorities are given and level of effort (LOE) is determined. If the LOE is high for a given bug and the priority is low (which it will be if there is a work around), that bug may exist for several development cycles.
>>
>>Just my $0.02.
>>
>>>This represents "one person" on "one product line" (kudos to him) ... and "one bug"; I wouldn't take it as an all pervasive philosophy/attitude across MS.
>>>
>>>I'm still creating work-arounds for VFP 3.0 bugs that (I guess) MS has deemed "too expensive" to fix (boo hoo).
>>>
>>>What's next ? ... It will be "un-american" to ask for (more) robust software ?
>>>
>>>Yep ... let's all sit back now and assume MS knows / does best ...
>>>
>>>Sorry, Garrett ... I don't ship software with "known" bugs, particularly in subsequent releases; and I won't buy into the concept that it's an acceptable way to run a business ... if you care about your users ...
>>>
>>>>Joe Bork wrote an interesting defense of why Microsoft would ship a product with known bugs. I recommend it.