The Old New Thing

Bravo!

Did they ever develop the debugging and analytical skills to solve their own problems?

That's an interesting use of the verb "volunteer."

That's an interesting use of the verb "to volunteer."

Sometimes a person that is not burdened by a project's idiosyncrasies can be quite helpful to get a project unstuck... Still, "so that I could magically resolve all their issues" is not something such a person could possibly do :-)

Reminds me of the line we used all the time in the MSRC back in the days when people would scream that they'd have us fired if we didn't let up/cave in/let them ship despite that security bug.  The line is best delivered in person, with a completely straight face.

"That's outstanding.  I long for the sweet release being fired will bring.  Fix the bug."

S.

Sounds overly rehearsed (but nice, nevertheless). Here's mine:

"So fire me. But you still have to fix the bug."

Social skills are a polite fiction we create and maintain to increase the size of our social circle.

If your social circle is already too large, rudeness is helpful in controlling the expansion of the circle.

Basic supply and demand.

There's a much easier solution.  Just let me discover the bug.  Then no one will have to fix it.

Norman Diamond wrote "There's a much easier solution.  Just let me discover the bug.  Then no one will have to fix it."

Perhaps I'm missing something, or are you working in PSS or even on documentation, meaning you could just document it "As designed"? Something else?

Wednesday, December 27, 2006 9:47 PM by Mike

> Perhaps I'm missing something

I'm going to partly answer Mike's question.  Sorry for the apparent hijacking.  Everyone else please skip this answer.

The first reason why bugs that I discover don't have to be fixed is that I'm not a Microsoft employee.

Ordinarily Microsoft doesn't allow customers to submit bug reports except after customers pay fees, and there are limits to my altruism.  In some countries Microsoft says that Microsoft can decide to refund a fee if a Microsoft engineer determines that a particular fix will solve the customer's entire problem, which would leave me in the lurch even if I were to be sufficiently altruistic.

One time Microsoft accidentally allowed communications between a PSS manager and myself, still resulting in Microsoft's refusal to fix a very serious, 100% reproducible bug.

Several years ago an MSDN downloading tool specified an e-mail address to contact about bugs reported by the tool, so when I quoted a bug that the tool reported to me, Microsoft told me to obey the instructions -- which is exactly what I had done by telling them what their tool had told me to tell them.

When eVC++3.0 reported an internal compiler error and said to view some Microsoft web page to report the error, the page said that if I pay a fee of US$190 then I could report the internal compiler error to Microsoft.  I didn't do that either.

Most of the Visual Studio 2005 bugs that I reported on the Connect site were decided as "won't fix", not only for service packs, but even for the next version of Visual Studio after Visual Studio 2005.  Fortunately an exception was made for one very serious problem (fixed while Visual Studio 2005 was in beta) and also another exeption was made for a nuisance issue (changed from "won't fix" to "will fix").  These are exceptions though.

Most of the Vista beta bugs that I reported on the Connect site were closed without any explanation, resolved as "by design", resolved as "won't fix", etc.  These include some very serious bugs.  One bug zeroed a disk drive's MBR together with BSODing.  I booted Knoppix and used a GNU tool (forgot which one) to recover the partitions.  The automatic repair tool on the Vista DVD still couldn't recover the Vista partition to a bootable state, though the files were visible under Knoppix.  On another machine, BSODs are 100% repro under Vista including RTM, though apparently fixed in Longhorn Server build 6001.

You must pay MS for reporting Bugs?

That is insane ..

------"You must pay MS for reporting Bugs?

That is insane .."-------

And insane is what you often end up as when trying to do it.

i've got to admit, i don't really understand the point you're trying to make.

what does the quote mean? what are you threatening? that you'll take some holidays? why would they care? they'll just ask you when you come back ...

The implication is that there is a looming deadline that may be missed if Raymond makes good on his threat.

I'll admit I don't dive into the guts of the OS very much, but every time I've been writing software and there's been a bug or piece of documentation that is wrong, MSFT has gotten me in touch with engineers who help me reproduce the problem and then tell me if I'm crazy or it really it a bug/error.

I've never paid a dime.

I believe the reason that you have to pay to report a bug is because if everyone that thought they had an issue with a MS product reported every bug for free and MS used as many developers as necessary to investigate the bugs, they'd lose millions on things that were not bugs at all and probably not even related to their software.

It is not within our rights as users to have bug-free software (read your EULA).  Not saying it's wrong to provide free tech support, just that some things are even beyond the developers' controls.

They also charge for membership to Xbox Live, for approving drivers, and for various other things.

The Xbox Live fee is to prevent kicked/banned people from just opening new accounts and harassing all over again. Anybody who's played online PC games knows how ineffective kicks and bans are when accounts are free and easy to create.

The driver fee is to prevent companies from using Microsoft as a free QA tool.

I find when MS charges fees for something, there's usually a good reason for it.

I've never heard of a charge for reporting bugs.  (Also, please keep in mind 100% reproducable BSOD's are not always bugs.  For instance I have a stick of RAM that if I put it in one particular laptop running XPSP2, it blue screens.  Put that same stick in another laptop with the same build, no blue screen, probably due to the completely different underlying chipset drivers.  Put WinXP SP1 on the first laptop, no blue screen.  Sometimes software can cover up bad hardware or reveal bad hardware, but the root cause is still bad hardware)

For instance, for security vulnerabilities you report those to secure@microsoft.com.  It's monitored by real people 365 days a year.  You will get a response within 24 hours.  There's never been any type of fee for that.

I think maybe you just have had some bad experiences with our support, which is inexcusable in and of itself, but it is not our policy to "charge you a fee for bug reporting".

"You will get a response within 24 hours."

Ho ho ho.

I wrote on Nov 24, and again on Dec 22 (even with a copy to stepto@...).

And I still got no answer!

ITS REALLY REALLY SAD THAT MSFT DOESNT CARE ABOUT TRUSTWORTHY COMPUTING!

nuff said

you sure you used secure@microsoft.com and not security@microsoft.com?

I've looked at my email, I dont have a vulnerability report from you at stepto@stepto.com or stepto@microsoft.com.

Could you resend?

I don't think you have the social skills of a thermonuclear device.  I mean, it's an okay title for a post, I guess, but inaccurate.  This case, for example, was simply another group trying to take advantage of you after they had failed to plan sufficiently.  Your response was not unjustified--or even rude.  In my opinion it is the people who are to lazy to use the tools they have, the people who don't bother to debug it themselves first, etc, who lack social skills.  Is work ethic a social skill?

Norman is just plain wrong. Microsoft DOES NOT CHARGE YOU TO REPORT A BUG. Microsoft charges you to open a support case after the free support period on your software has expired. This is not unlike the diagnostic fee that you pay when you take your car to a dealership after the warranty period has expired. When opening a case with Microsoft, if the problem you are experiencing is determined to be a bug, that charge will be refunded. If the problem you are experiencing is determined to be "By Design" then your money may or may not be refunded but it is quite possible that a bug will be filed for consideration against future versions of the product. As with most things your ability to get a refund partially dependent on your persistence and your ability to make a case that the problem you are experiencing is due to a flaw in the product or faulty design.

There is one exception to this behavior and that is for our Premier customers (http://www.microsoft.com/services/microsoftservices/srv_prem.mspx). These customers pay in advance for support and a more intimate relationship with Microsoft. Part of the benefit of that relationship is the ability to request that Microsoft make changes to the design of a product in the form of a hot fix. This type of request is usually called a Critical Design Change Request.

When considering whether or not to fix a bug a or accept a Critical Design Change Request many things are taken into account, here are a few  in no particular order:

1. Is this a security flaw. (ALWAYS GETS FIXED)

2. Size of the code change required to resolve the problem.

3. Impact of the problem on the usability of the software.

4. Number of users impacted.

5. Is this a Premier customer or Partner.

6. Size of the customer and their investment in MS products.

7. Can the code change be delivered in a hot fix. For example, setup problems often cannot be resolved with a hot fix because the product is not yet installed.

Here are a couple of quick definitions to clarify things a little(mine):

By Design

The feature or behavior is working as designed. Unfortunately, the design may not take into account all possible uses or configurations of the product. This resolution is typically applied to problems where a customer is trying to do something never intended to work in the original design of the software. Often times if the problem the customer is experiencing impacts a lot of customers or is the result of a documentation error or omission then you can get the cost of the support call refunded.

Won't Fix

Microsoft has identified this as a flaw in the product but has declined to provide a hot fix. This is usually because the changes required to resolve the problem are too large to ship in a hot fix or service pack or the repro scenario is so odd that only a very small subset of customers will ever encounter the problem. In most cases you should be able to get the cost of the support call refunded.

Many problems are resolved as Won’t Fix or By Design because a workaround is available. Sometimes the workaround is acceptable to the customer, sometimes not. Just because you don’t want to do something a certain way doesn’t mean that the products is flawed.

There are a other mechanisms to file bugs as well but I don’t know what they are off the top of my head. You used to be able to e-mail mswish@microsoft.com  but I think that is dead. In general, if you have a problem that you believe is a bug you should do the following:

1. Search the Microsoft Support Knowledge Base (support.microsoft.com)

2. Search the web for solutions, workarounds, references to others having this problem.

3. Open a support case with Microsoft.

I know there will be much wailing and gnashing of teeth over this, cries of favoritism and general complaining that Micro$oft is evil but in reality most large software companies operate this way. I simply offer this as a clarification to the FUD that Norman posted above.

@MS-CSS:

"Won't Fix

Microsoft has identified this as a flaw in the product but has declined to provide a hot fix."

Thank you very much for explaining this.  The name of this bug resolution has caused a lot of pointless angst in the dev world:  "I reported a bug, an obvious case of something quite wrong, and you're telling me you won't ever fix it in any future version?!"  But it makes perfect sense that such a problem might be too involved for a hot fix or service pack.

The trouble is that "Won't Fix" sounds like you are discarding the report entirely.  Aren't these things scheduled for a future revision or rewrite of the program?

Maybe a bug is too complex for anything but "that will have to wait until the compiler back-end rewrite planned for Visual C++ 15."  Then when the rewrite happens, the devs get to take credit for having finally fixed a big old bug!

"Won't Fix" is a poor name (or it implies a strange approach to improving products).  I'm glad to finally learn what it really means.

@stepto: thanks for taking things up!

Of course I used <secure@...> and set <stepto@m...com> Cc: this time.

I'll resend it to both of your addresses.

BTW: I'm still missing a note when the error in PPT viewer 2003 I reported more than a year ago will be fixed. Alexandra Huft was involved.

@Raymond: sorry for the hijacking...

Daev

The bug resolution codes such as "Won't Fix" and "By Design" are really just general flags in a database. Different product teams treat them differently. It is quite possible that a bug filed against v5.0 of a product may be rejected as Won't Fix and simultaneously a new bug is opened against v6.0 that addresses the problem. As a general rule when your case makes it to the point where a bug is filed for your problem you should be told the outcome of that bug request in plain English and not simply be given the bug database flag. In other words, if the engineer working your case tells you the product group rejected your bug request as “Won’t Fix” you should ask if that means they will never fix it or if it means they won’t fix it now but will consider it for a service pack or the next major release of the product.

I know of no product team within Microsoft that doesn’t want to create the most solid, flexible product they can but they are often constrained by forces outside of their control. On top of that, the development team that supports a product after its release is usually not the same team that wrote the code prior to release. These sustained engineering teams have budgets, goals and restrictions that are VERY different from those of the team designing and developing a major release.

Raymond: Sorry for hijacking your blog comments but I’m too lazy to have my own blog and this is as good a place as any to disseminate this information.

As a former MS engineer, I can reiterate what MS-CSS states.

When I first started at MS, I was a "purist" and felt that every bug should be fixed. Regrettably, it just isn't possible. Having consulted for other companies since then, I can state that this is the case at every company I've worked for. I'm surprised that Norman hasn't had that experience as well.

As far as reporting bugs, I've been working with Windows Presentation Foundation and submitted a fair number of bugs against the CTPs and Betas. Every one of my bugs received a response and often an explanation. Yes, some were marked "Won't Fix", and I certainly disagreed on some of those, but I'm not working under the same constraints as the WPF developers are. And no, I have no special "in" by being former MS. I doubt they know I'm former MS anyway.

I believe there are bug forms for every MS product (I might be wrong on that, but I'm pretty sure they exist). Yeah, sometimes you get Won't Fix on some bug that really irritates you, but remember that there are usually hundreds of thousands if not millions of other users out there. Sorry, but if your bug is obscure, it just doesn't rate that high. On the other hand, if several hundred users report the same thing, the bug starts to rise up and become more visible to the product team...

I think MS is just being pragmatic, not evil.

At my previous job we had a term: volun-told.  It is like a request except you don't acquiesce; you are expected to initiate the transfer yourself instead.

This must be some management kung-fu, passed from one DM to another DM like a masonic secret.  It is as if they believe I am going to feel better being whored-out to another department because I am coerced into offering my services.

Saying yes to such tactics leads to one thing only: you get taken for granted.  In my experience promotion comes from pushing your own agenda and not fulfilling the agenda of other people (like those who are insisting on you volunteering).

Funny, I thought Raymonds response meant that he would say yes and then take a vacation just on the week agreed upon ;-)

"It is quite possible that a bug filed against v5.0 of a product may be rejected as Won't Fix and simultaneously a new bug is opened against v6.0 that addresses the problem."

Then the "proper" thing to do would have been to put the new bug number in the comment field along with a description saying that a new bug has been opened for this future version.  Otherwise, it appears that the user's request has just fallen into /dev/null.

I quit a job once so my 4 weeks notice was up 2 weeks before The Unmissable Deadline*. As I was The Server Software Expert this really screwed them. They asked me to stay the last two weeks and I said "Nope, I'm going on holidays". However, they offered a ludicrous hourly rate so I signed on for the two weeks.

Ever worked during a project's Crunch Time where your colleagues are working 18+ hour days and you are kicked out after 8 (rememeber it was an hourly rate)? Amazing how productive you can be fully rested.

Anyway my point is my boss's boss had made the deal with me. When my boss found out it was thermonuclear WWIII.

* I quit because my boss + I had such a dismal relationship it was affecting my health. She was fired soon after the project went live.

[The internal bug almost certainly has such a comment, but I suspect that the tracking system does not send developer bug comments back to the external bug filer because bug comments usually contain confidential information (like names of internal functions or discussion of how a chunk of code works). Just guessing. -Raymond]

I was referring to the user-visible comments section.  Putting it in the restricted section obviously does the user no good, and doesn't change the user's perception that the bug has been ignored.  I can't believe that I had to write that.  ;)

We (at least some of us) were specifically discussing items reported to the Visual Studio team through Microsoft Connect.  It does have such an area.

Microsoft posts publicly visible comments in the Visual Studio area more often than in the Vista beta area, but that is not the only area.

User-visible comments varied in quality as much as other forms of communication did.  Even in cases where Microsoft asked for further information and I provided it to the best of my ability[*], bugs did not get fixed in Vista, though it seems one was fixed in Longhorn Server.  The few bugs that were resolved to be fixed were very minor.

[* The worst example was when Microsoft asked for a full memory dump which Microsoft would never accept.  I spent a couple of hours uploading it before learning that Microsoft would not accept full memory dumps that exceed 50 megabytes.  Other examples were not so bad, but still didn't bring fixes.]

"I have a lot of vacation days and I'm not afraid to use them" - I took this to mean "use them to fix your bugs", ie that he was offering to use his vacation time for fixing bugs on the other project.

After all, if he has *that* many vacation days he obviously doesn't need them for vacations.