Compartir a través de

The glass is also half full...

  • Artículo

I've posted recently about bugs we havent been fixing. I fear this tends to put a negative touch on the great job our team is doing in fixing other, more important bugs. Our triage team sat down today and looked at fix rates over the last year, and our fix rate for bugs last week matched one of our top 3 weeks last year! Thats pretty phenomenal!

Mike Sampson does a pretty good job of describing our shutdown schedule here: https://weblogs.asp.net/misampso/archive/2005/01/19/356194.aspx. As we shutdown into tell and ask mode for Beta2, we use a written bar to judge every bug that we fix. Our bar is kind of lower than the one I'm going to chat about - but eventually we want to be fixing only the following sorts of bugs. One other important thing - the list below is a guideline. If I had a nickel for every time someone has brought a bug, that we needed to fix but wasnt on this list...I would be sipping fruity drinks on a very nice beach in Hawaii right now. Anyway, here goes -

a. Crashes and hangs. Pretty obviously, its no fun if the product comes crashing down just as you are doing a sweet refactoring. In past product cycles, we also get feedback from Beta release users of the most common crashes reported by Watson, and we fix them.

b. Security issues. If evil hacker dude, script kiddy etc...can easily take your machine over, we will fix it.

c. Bugs in major customer scenarios. If refactoring is a bad experience or Enc has bug that just drives you nuts - we'll fix it. Its a sort of multiplier effect almost - a small innocuous bug in a scenario used one grillion times ranks as high as a major bug that could be run into not very often.

d. QA blockers. If our tester guys - our last line of defense against a paltry product - cant run tests because of a bug, we would take it.

e. Performance blockers. If this bug blocks your debugger from launching an app fast, or other scenarios (soon to be blogged about), yeah we would fix that.

f. Regressions from VS2003 and VS2002. Past product usage sets expectations and we dont want to break that experience (unless planned, such as keybinding changes).

g. Fixes we want feedback on. We love Ladybug bugs and we would take fixes that we want you  our customer to tell us - hey thats cool, or hey what were you smoking?

In case you're wondering, I havent put in any specific bugs - I shy from that now in case we get a regression, or the checkin isnt right. Suffice to say, we are fixing a bunch of bugs too, so please keep your Ladybug feedback rolling in!

Shaykat

Comments