How do you ship software?

I surely don't need to tell you that we've been working on Whidbey for a while now. You probably wish we would hurry up & ship the thing. Me, too.

However, we still have some bugs left to fix. Most were found by our QA, but many came from Ladybug. Thanks for all of those.

We also got a whole lot of good suggestions via Ladybug. While we'd like to implement many of them, doing so is counter to the goal of shipping this product. So most of the ones I see, I resolve as Postponed. You get a comment from me saying "thanks, but no thanks". It'm bummed to write these comments, because I really want to get customers more involved with how we create our software. Your suggestions will be considered next time, though. 

One thing that always happens is that you look at some feature and realize it has some serious problems. You need to rewrite a peice of it to really fix it right. It's really hard to say no on these, but the time has come. We gotta shut down.

One of the techniques we use is "staged goals". Suppose a team has, say, 100 bugs per dev, and we intend to hit 0 bugs in 10 weeks. To do that, we need to drop by 10 bugs / dev / week. So say we'll hit 70/40/10 bugs per dev, every 3 weeks. It's a good way to make sure you're on track.

Trouble is, we're not on track. We still have too many bugs to fix in the time that's available. We don't want to slip the product, but we do want deliver high quality.

Over the last week I've been combing through the bugs on my team. I read each one of them. I verify that they still exist in the latest build. 

I also look for bugs that we can punt. (By "punt" I mean not fix in Whidbey.). Some get resolved "Postponed", which means we'll look at them again next time. One of the problems with Postponed is that there are some bugs we postponed last time (and the time before that). If we are postponing it repeatedly, we'll probably never fix it, and should resolve it "Won't Fix". That saves us the time spent reviewing it every product cycle.

There's another class of bugs I like to resolve as "Won't Fix". They're real bugs in the product, but it's not clear whether customers will ever run in to them, or care. So we Won't Fix, and assume that customers & dogfooders will tell us if they are annoyed. If it never comes up again, then we don't have to fix it.

We're also doing something usual. Sometimes we look at a bug and think "I'd like to fix this, but I wouldn't hold up the product for it." We're marking these bugs as "puntable". If the ZBB date slips, or we clear out our bugs faster than expected, or magic happens, then we'll fix these. But if things continue the way they're going now, we will resolve them before the ZBB date as Postponed.

As you can imagine, reading through every bug on my team is time consuming. There's some other stuff going on, too, hence not much time for blogging.