Today I got to present a bug in Developer Division shiproom.  I haven't gotten to present since Beta 2, as ScottNo has being doing it for C# all this time.  He's doing a fine job, but I get a real rush out of it.  I like the feeling of having all the answers lined up and presenting well.

It comes from a lot of hard work beforehand, of course.  I spend a lot of time studying the bug and asking the developer & tester some hard questions:

• If we created this bug, does that mean we made similar mistakes elsewhere? 
• Are there more bugs waiting here? 
• If we were confused about this before, why do we think we can get it right this time?
• How long has the bug been in the product?
• If test didn't find the issue before now, why do we think we can confidently test the fix?
• If test didn't find the issue before now, how many other bugs have they not yet found in the area?
• If we know there are more issues in the area, will fixing this really improve the customer experience, or will they still think it's junk?

This particular bug had been in the product for 14 months before we found it.  It's clear that no one had ever executed this broken line of code - not dev, not test. 

One of the hard parts about this decision is that, while the scenario was in the "design time" (it affected debugging), the fix was in a "platform" component (the C# compiler).  If we get it wrong, we could potentially break the .Net Redist, every app that you create in C#, cause the CLR to miss its stress-test goals, and cause Whidbey to slip.  (I don't think any of this will happen, but it's good reason to choose carefully.)

There were 7 reports of the issue from Beta 2 customers.  That was a factor in deciding to take the fix.  Thanks for hitting "Send Report" on a hang, folks!