Share via

Won't Fix or Postponed?

  • Article

In our bug database, when resolving a bug, you have to select a “Resolution”. Obviously you can resolve as “Fixed”. Other options include:

        By Design - this isn’t a bug, we meant it to work this way.

        Not Repro - you were mistaken, this bug doesn’t exist.

        Postponed - this is a bug, but we won’t fix it this time. Will reconsider next version.

        Won’t Fix - this is a bug, but we won’t fix it, not even in the next version.

There’s an interesting tension between Postponed and Won’t Fix. A Won’t Fix bug gets “lost” into history. (Actually, the bug database is always around & available to be queried, for all of eternity.) If you see a bug resolved Won’t Fix, you might worry that we’re dooming ourselves to shipping the next product in a broken state, too.

Near the end of each product cycle, we sit down to review all the Postponed bugs. It involves several of the leads from the team, and can take days. We’re looking for two things:

  1. Bugs that we should fix next version / features that we should plan to do
  2. Bugs that we should fix right now in the current version. Last chance! Pretty rare.

Then, shortly after the start of the next product cycle, we sit down to review all the bugs again. With a rough feature list & schedule in hand, we make sure that the bugs are assigned to the right person, that our feature plans take these bugs in to account, and that we have enough time set aside to fix the bugs we want to fix.

It’s a tedious & expensive process. And it’s often not very worthwhile. There’s a set of issues that we keep postponing every time. (Not many in C# IDE because it’s still pretty new, but on my old team this was pretty bad.) I think this is because these bugs really aren’t important enough to spend time on. We should put our time somewhere else.

When selecting between Won't Fix and Postponed, here's what I look at:

- If there's important information in the bug, like design decisions or the results of detailed analysis, then Postpone so we keep that information.

- If it's a real bug, but in a corner case that most people may not care about, I'll resolve it Won't Fix.

If we made the wrong choice (should have fixed it), we'll hear about it, from customers, partners, and dogfooders. Having the bug won't be an important part of our decision to fix it next time.

If we made the right choice (users don't really care), then we never have to think about it again.

- If it's a bug we know we want to fix next time, and there's a chance that we might forget to fix it otherwise, then Postponed.

- If the bug is something we won't fix without re-architecting the system, but is something we'll probably think about during the re-write work, then I resolve Won't Fix.

- If the bug came from ladybug, it nearly always gets Postponed. That because a customer has actually said they want the bug fixed. And because the sample set (beta users) is pretty small, the feedback should be taken seriously.

As you can see, I’m pretty hard core about marking as much Won’t Fix as possible.

Comments

  • Anonymous
    September 16, 2004
    I think that having a set of bugs continually pushed from release to release can be a symptom of a serious problem. It's a similar principle to conducting a ZBB. When you stare at a list of bugs too long, you can start to fool yourself about the progress you're making and whether the expectations you have are realistic. You need to show that your bug counts really are going in the right direction, and fast enough.

    I infrequently try to do an Old Bug Bounce. I'll pick a cut off for a bug filing date and spend some time attacking any bugs older than that. At the end, I've either fixed all the older bugs or decided that they just aren't worth fixing. Either way, I don't have to look at them again unless someone files a new bug report. If it's been 3 years since anyone complained and we're still unwilling to fix the bug now, it really can't be that important of an issue.

    Another thing I think makes it easier to won't fix is to have a failing test case for the issue. It's a bigger reminder that there was an issue we decided not to deal with than a closed bug. Bugs get resolved for a lot of reasons, sometimes not very good ones, but a test case actually shows today's code not able to do something. Plus you'll immediately find out if someone managed to fix the bug accidentally.
  • Anonymous
    September 16, 2004
    How well is this working for you?

    "If there's important information in the bug, like design decisions or the results of detailed analysis, then Postpone so we keep that information."

    Is it a time sink having to keep the bug on your postponed list? I usually end up having to transfer information like that to small web articles. People tend not to find things inside of bugs, especially the newer developers. I think the search tools may need improvement to make this work better.

    Anyways, I really enjoy these kinds of articles. I've actually tried out some of the process things you've blogged about.
  • Anonymous
    September 16, 2004
    I wasn't sure if this kind of article would be useful to my readers. I was actually afraid you might read this and say "oh, they're going to ship buggy software". Well, of course we'll ship with some bugs. The question is whether we fix the right set of bugs so that you're happy & productive. Tough question...

    So far, it seems to be working pretty well. It takes courage and strength to mark a bug as Won't Fix. To stand up and say "I'm confident that we're doing the right thing by our customers by resolving this bug Won't Fix".

    But I think in the long term (multiple product cycles) it will be quite valuable.
  • Anonymous
    September 21, 2004
    For a suggestion I submitted recently, MS set the resolution as "Won't Fix", but then while doing so, added a comment saying "We are unable to address this issue at this time, we will consider it for a future release."

    With that comment, shouldn't the resolution have been "Postponed"?
  • Anonymous
    September 22, 2004
    Hey Adam,

    I wrote this talking about how I manage bugs for my team. VS is so large that it's normal for different teams to manage their bugs differently.

    Perhaps they're tracking all suggestions in an internal TODO document, and don't want the double-accounting of a postponed bug.

    If you think that your issue isn't getting the attention it deserves, you should push back on it.