Microspeak: Bug jail


Bug jail is not a place where bugs are sent as punishment for their crimes. Rather, it’s a (virtual) place that developers are sent when they have too many bugs.

Project management establishes some maximum number of bugs (known as a bug cap) each developer is permitted to have on his or her plate, and developers whose bug count exceeds the specified maximum are placed in bug jail. The precise triggers for bug jail vary from team to team, and it may vary based on the nature of the bug. For example, one trigger might be that any Priority 0 bugs more than 24 hours old will land you in bug jail.

Once you land in bug jail, you are not allowed to do feature work, be it coding, writing specifications, whatever. The precise triggers for getting out of bug jail also vary from team to team, but one rule might be that you need to get your bug count back down to 50% of the bug jail trigger level before you are allowed to exit.

Staying on top of your bug count is an important part of the software development process, and the primary motivation behind bug jail is not to punish developers, although I’m sure that’s how most developers perceive it. Rather, it serves as an early-warning system to highlight things that are not going smoothly. There may be a bug farm developing in that feature area. Or the team needs to revise its idea of what it means to be “done” with the feature. And it’s a signal to project management that they may need to scale back their plans so as not to compromise quality and the ship schedule.

When everybody understands the reasoning behind bug jail, you avoid lengthy discussions over boundary cases (“What if a developer is about to check in a feature but a low-priority bug comes in that pushes them over the limit?”) and avoid discovering that people have been “gaming the system” (for example, by reclassifying bugs as feature requests so they don’t count toward the bug cap). Like bug hugging, these sorts of games prevent project management from truly understanding how close the project is to being finished.

Comments (20)
  1. configurator says:

    Maybe people would try to avoid it less if you didn't call it bug jail, but something that sounds less like a punishment. Getting promoted to the Anti Bug Squad, for example.

  2. John says:

    @configurator: A rose by any other name…

  3. Joshua Ganes says:

    As a general guideline, this sounds great. It's a bad idea to let your bugs grow out of control while you work on new features. Fixing bugs quickly reduces development time and makes it easier for the rest of the team to work with each developer's features. Using this a hard and fast rule can lead to some really silly behavior that can cause more harm than good. From your last paragraph, it sounds like this is not allowed to get out of control.

  4. The idea sounds sensible, certainly – in part as a safeguard against people pushing you for features in place of fixing bugs.

    "Could you make Explorer steam the milk for my coffee when it boots up?"

    "No can do, bug jail"

    More diplomatic than having to explain 'sorry, your milk-steaming request is a lower priority than that other guy's request for a cup-holder', at least.

  5. John deLaubenfels says:

    Whatever they're doing, it doesn't seem to have stopped many bugs getting out to customers.  People on my team are hitting a VS2010 bug in which one or more local variables are greyed out in the debugger's Watch window ("CXX0017: Error: symbol "fBestZ" not found").  Can't be inspected, can't be modified.  Apparently Microsoft is aware of the problem but has no plans to fix it until VS2012 (?).  Needless to say, a debugger has limited use under these circumstances.

  6. DrkMatter says:

    @John deLaubenfels

    "Whatever they're doing, it doesn't seem to have stopped many bugs getting out to customers."

    And how exactly do you derive your metric of how many bugs were stopped? The amount of bugs in a project after its release is not a reliable indicator of how many were found and fixed during development. But I understand that an overwhelming desire to complain can blur the lines of logic.

    At my previous employer, I used to be one of the few developpers who liked fixing bugs better than writing new features. Bug jail sounds like a fun place to me!

  7. John deLaubenfels says:

    @DrkMatter

    "And how exactly do you derive your metric of how many bugs were stopped?"

    Sorry, my wording was unclear.  I didn't mean to imply that they don't catch a lot of bugs, only that many still get through.

  8. James Schend says:

    @John deLaubenfels

    But mostly you wanted to complain.

  9. steveg says:

    @James Shcend: you posted to complain about complaining?

    string s = "@steveg: and you just posted to complain about complaining";

    while (true)

    {

       s += " about complaining";

       Console.WriteLine(s);

    }

  10. Silly says:

    @steveg.

    Your infinite loop has a bug: it will exit when the string reaches its maximum size or the system runs out of memory.

  11. Even More Silly says:

    Also this is not a .NET blog, so your silly code samples should be in C++, not in a .NET based language.

  12. Cheong says:

    Just call it "bug queue threshold", and it accurately describe it's purpose (If it reach threshold, you shouldn't put more things in it, and you should stop doing anything that'll put more things in it).

  13. @steveg.

    Yo dawg. I heard you liked complaining so I put some complaining in your code so you can complain while coding.

    Complaintception.

    Ok, that's the memetic stuff out of the way.

    WriteLine? Are you sure you're calling the right there?

  14. Pessimist says:

    If some new bit of code is generating enough bugs to put its developer into bug jail you're probably better off keeping that developer off of new features. Bugs don't come from the code, they come from the developers. Of course this breaks down if the bugs are not assigned to the developer who wrote the buggy code.

  15. Every developer from the Vista/7 shell team should be sent forever to bug jail! Still not fixing bugs that surfaced and were reported since Vista.

    [This is what happens when I forget to add a pre-emptive snarky comment. Sigh. -Raymond]
  16. steveg says:

    @even more silly: I prefer Db to C#, it's easier to deal with.

    @lockwood: I suppose you could do this if you don't want to use Console, it's what I use, I find it far more convenient than using your browser to post a reply.

    using System.Blog;

    Blog.Post("blogs.msdn.com/…/oldnewthing", "steveg", s);

  17. Maurits says:

    As the signs on the bus used to say – when crossing the street, if you don't C♯, you could B♭

  18. Maurits says:

    (Funny that this should come up today.  I just wrote an app that translates note names to Hz values.)

    blogs.msdn.com/…/beep-sample.aspx

  19. @steveg

    I would have thought Write would have worked better than WriteLine.

    I then realise dwhen doing some copy and paste that you were not just reprinting " about complaining", but the entire message again and again, so I retract my comment.

  20. B says:

    Individual contributor bug counts are ignorant of the fact that we now live in a world where software is such a community driving process that any individual's bugs are not consequential.  The bugs belong to the common consciousness.  Although there may be individuals better at fixing the bugs, or ignoring their presence, the responsibility as a whole lies on every developer.

Comments are closed.