How a bug becomes a fix…

Anonymous Corporate Coder wrote a comment on my ZBB post, asking what set of bugs ZBB relates to.

I started to update that post, but it quickly expanded, so I've decided to write a separate post.

We're organized around a milestone approach. Some milestones are date-driven, some are quality-driven, and some start as quality driven and change to date driven.

As we code through a milestone, all bugs belong to that milestone, and as we start to push towards ZBB, we will be tracking all those bugs. At some point along the march to ZBB, we will start moving some bugs to a later milestone if there is one, or postpone them for this product.

Whether a bug gets moved or not depends upon a lot of factors. If we're quality driven, we will punt fewer bugs beyond the milestone. If it's the last milestone of the product (RTM), we punt fewer bugs. We have an elaborate way of describing whether bugs are fixed or not (Gus, if you're reading this, how about a post on bug bars?).

That will get us to a set of bugs we believe should be fixed in a specific milestone, and we drive to get that fixed.

On the C# compiler team, we try not to punt bugs, especially if its the last milestone.


Comments (2)

Skip to main content