Picking what to work on, and banging my head against a bug.


Lately I’ve just been working on bugs.

When you have quite a few bugs at the same priority level how do you pick which one to start on? I tend to go for recent bugs, then bugs that may need to go to someone else, then bugs I think will be easiest to fix. I used to go to the hardest bug, but this has the horrible property of leaving bugs that someone else needs to look at bunched in your queue until you diagnose the hardest bug you have. I tend to find diagnosing the problem is the part that takes a bunch of time, rather than fixing it once you know what’s really wrong.

I will still foolishly beat my head against a bug once in a while. Such as today. This afternoon I started tracking down a high priority bug in native retail code. Debugging retail code is harder because the debugger will get variable values wrong depending on compiler optimizations. You basically must look at the disasm to figure out what’s going on. I eventually got far enough to determine that some specific objects are leaked and are the cause of the problem. Now in code compiled with the debug flag, we track these objects, but rather than step back and replace the 6 dlls I need with debug versions I wasted another hour trying to track AddRef/Release calls through the retail code.

Comments (5)

  1. J.P. says:

    Dont forget us testers! Try to think of us when ordering/triaging bugs. By fixing certain bugs that we are blocked on, it can really help out test development or execution.

  2. SteveJS says:

    That is a really good point. It is not one I think about often. If a tester tells me they are blocked on a bug I will up it’s priority. Otherwise I don’t think about it. Fortunately In practice most of our testers are good at making themselves heard when they are blocked.

  3. Eric TF Bat says:

    I’m pretty unscientific about deciding what bug to work on next (I usually go on some combination of intuition and laziness) but when I’ve fixed a bug, I usually sit back and ask myself, "What sort of tool would have prevented that bug for me?". For memory leaks, the answer is usually a memory logging class. Mind you, I’m a Delphi programmer, so I’m used to being able to create and destroy class instances at will, instead of hoping the garbage collector will do it for me.

  4. Mahavir says:

    Very very Good Point !