What is a BUGBUG?


One of the internal software engineering traditions here at Microsoft is the “BUGBUG”.

Bugbug’s are annotations that are added to the source code when the developer writing the code isn’t sure if the code they’re writing is “correct”, or if there’s some potential issue with the code that the developer feels needs further investigation.

So when looking through source code, you sometimes find things like:

    // BUGBUG: I'm sure these GUIDs are defined somewhere but I'm not sure which library contains them, so defining them here.
    DEFINE_GUID(IID_IFoo, 0x12345678,0x1234,0x1234,0x12,0x12,0x12,0x12,0x12,0x12,0x12,0x12);
 

The idea behind a BUGBUG annotation is that a BUGBUG is something that you should fix before you ship, but that won’t necessarily hold shipping the product for – as in the example above, it’s not the end of the world if the definition of IFoo is duplicated in this module, but it IS somewhat sloppy.  Typically every component has a P1 bug in the database to remove all the BUGBUG’s – either turn them into real bugs, or remove them, or ensure that unit tests exist to verify (or falsify) the bugbug.

As far as I know, the concept of a BUGBUG’s was initially created by Alan Whitney, who was my first manager at Microsoft – I know he’s the first person who explained their use to me.  Lately they’ve fallen out of favor in favor of more structured constructs, but conceptually, I still like them.

Comments (27)

  1. mschaef says:

    On my personal projects, I’ve adopted the convention of prefixing comments with varying numbers of ‘!”s to indicate things that need to be fixed. Rougly speaking, the meanings work like this:

    !! – Fix this sooner or later

    !!! – Fix this before releasing

    !!!! – Fix this before checking into CVS

    !!!!! – Utterly broken, fix before compiling

    Visual Studio’s "Find In Files" then makes it wasy to find all the things to do. If the entire comment fits on one line, the report produced by "Find in Files" turns out to be quite complete. If I got on the ball, I think these comments could even be integrated into the Visual Studio To-Do list feature.

  2. Steve Hall says:

    One word for these kind of techniques: quaint. No matter that we’re well beyond the 70’s and keypunch cards, we still seem to be using techniques that are overly-simplistic and hard to manage. (Probably because they work so well at keeping bugs quasi-secret; out of the lime-light of micro-managing project leaders and project managers!)

    I certainly hope the new technique that’s replacing this is well-integrated into the SCCS and build systems. Might it be a new feature of VSTS? If not, IT SHOULD BE… (Ten years ago, I was thinking of just such a source-code annotation feature that would be integrated into an SCCS that I wrote, with the annotations being stored in separate files. Of course, checkins would be extended to disallowing a checkin if certain annotations were ranked high-enough in priority or severity…which would be data from the automatically-generated PR, Problem Report, in the problem tracking system. The text of the annotations would appear in reports for a bug triage meeting between the project leaders and programmers…before the bug triage meeting between the project leaders and project managers. But, of course, since we were using quaint source-code annotations, I never got around to it!)

  3. AT says:

    BUGBUG: "either turn them into real bugs, or … "

    Cool practice… I was always wondering why such a smart and experienced developers working at MS has so many bugs – they add them intentionally to make less-experienced developers and customers feel happy then they will find/hit any of them 😉

  4. Paul says:

    Steve – oh, I dunno. ‘egrep "(XXX|TODO)"’ works pretty well at finding the points I marked for further attention. BUGBUG just sounds like a variant on that. I think most developers do the same thing.

  5. AT: Actually that’s why bugbug is out of favor – people took the term out of context and said that’s why Microsoft has so many bugs – they put them in the text.

  6. Dean Harding says:

    Where i used to work we used to have //TODO comments sprinkled all over our code with similar sorts of things.

    That is, until management decided that these "todo"s needed to be actually "done" and started generating reports based on the number of todo comments in our code.

    Needless to say, as soon as that happened, we started simply deleting the comments whenever we checked in (to keep the numbers down) and writing our *real* todos as //ODOT to fool their silly reports.

    I guess my point is that while formal methods for tracking issues are a good thing, you still need something more informal, if only to flag at a code review or something. Engineers are a funny lot – impose formalities on us and we’ll rebel any way we can 🙂

  7. C:WINDOWSINFmshdc.inf

    (Yes it’s on the C drive because I haven’t repartitioned and reinstalled the OS on this one.)

    From Windows 95 through 2000 there was a BUGBUG where the developer was asking what something does. My best guess is that it wasn’t part of the actual problems that Windows systems have had in handling disk drives though. In Windows XP it changed into an ISSUE (but there’s a new BUGBUG to make up for it). I forgot to look for it in Windows 2003. Maybe it’ll be changed in Longhorn tonight ^_^

  8. Anonymous says:

    Once upon a time (maybe still?), the Photoshop team called these "Bullshits". As in:

    //BULLSHIT: this should be calculated at runtime, not constant

  9. Sam Meldrum says:

    Dean – wouldn’t it be better to educate the management as to the meaning and importance of these comments rather than dispensing with a useful system of tracking such issues? Just a thought…

  10. Martin says:

    !! is not the best of flags to use: how else do you convert a sort-of-Boolean into a real-Boolean value?

    As BUGBUG being "quaint" – yes, but it’s robust too, and that’s more important. If it’s in ASCII source text, you don’t depend on whatever elegant source code maintenance system you are using still being around when you need to look at the code in 2025.

  11. Norman, good catch – whoops 🙂

    I just checked, it’s on my version of the INF file as well (on this machine at least), and that’s on XP… I’ve not checked W2K3…

  12. Martin: Absolutely. And thinking of it as ASCII art’s a fascinating idea, I wish I’d thought of it :). Given that NT’s gone through at least two different source code control systems (and has taken source projects in from still others), it’d be hard to imagine something like this that could survive too long.

  13. Martin: By writing

    real_boolean = (sort_of_boolean != 0) ?

  14. Purplet says:

    Martin :

    !! is not the best of flags to use: how else do you convert a sort-of-Boolean into a real-Boolean value?

    simply checking if the expression is different from its false constant ?

    BOOL bFakeBool1 = …

    int iFakeBool2 = …

    bool bRealBool1 = (bFakeBool != FALSE);

    bool bRealBool2 = (iFakeBool2 != 0);

  15. David says:

    In many open source projects I’ve seen the FIXME marker instead.

  16. Jonathan says:

    I believe the infamous "Windows 2000 shipped with 63,000 known bugs" was referring to bugbugs… gotta love the press.

  17. Chris says:

    I use FIXME and TODO when I’m adding "buggy" code, but I use BUGBUG? when I’m noting a possible bug in someone else’s existing code. <:)

  18. mschaef says:

    "!! is not the best of flags to use: how else do you convert a sort-of-Boolean into a real-Boolean value? "

    As Purplet pointed out, an explicit check; That’s more readable to me anyway. Had I been using the !! idiom when I started using this kind of comment, I probably would have picked something else (@@, @@@, @@@@, @@@@@, perhaps).

    I do agree with you that (in theory) picking a flag character that matches a language operator isn’t so bright. In practice, it hasn’t been an issue for me at all, even in commercial development.

    "One word for these kind of techniques: quaint. No matter that we’re well beyond the 70’s and keypunch cards, we still seem to be using techniques that are overly-simplistic and hard to manage."

    Even if it is hard to manage, it’s easy to use. A flag comment can be entered in seconds without changing to a different editor or window, refers directly to particular code, and is trivially easy to query for. For light weight little annotations, it’s hard to imagine a more ‘engineered’ system offering a decent ROI.

  19. I’m not sure that count was referring to, but I do know that pretty much everything you can imagine that you might want to change about the product gets tracked as a bug, including all manner of suggestions and trivial cosmetic issues.

    I’m sure there’s a dialog box somewhere in Windows where a control is one pixel too far to the left. Well, that’s going to be a bug in the database, but (quite correctly) it would be decided not to hold up shipping the product to fix such a thing.

  20. Mike says:

    Jonathan mentioned media and their misrepresenation "Windows 2000 shipped with 63,000 known bugs".

    Partially kidding, but…

    How large is the bugfix list for NT5sp4 now? ;->

  21. Chris Walker [msft] says:

    Most of the reported Windows 2000 bugs were produced by a static analysis tool run just before we shipped, but before we could fix them. We probably should have waited to move them into the bug database until after we shipped, but who was to know that these numbers would be leaked to the outside world. Many of these bugs were not bugs, so the number is certainly inflated.
    <br>&lt;p&gt;
    <br>At least we weren’t hidding bugs from ourselves. There was a push to get rid of BUGBUGs from the source, so groups just replaced them with other keywords instead of addressing the issues they were documenting. But they didn’t use the same keywords across the whole source base.
    <br>&lt;p&gt;
    <br>I found it assuming when I discovered BUGBUGs in 15 year old code I work on changed to FEATUREs by someone who at least had a certain amount of humor.

  22. kalleboo says:

    So know that we know what a BUGBUG is, what’s a BIGBUG? 😉

  23. Phaeron says:

    Where I work, we used to have a macro that turned TODOs into #pragma message statements, but it fell out of favor because the compiler output got cluttered with trivial, low-priority fixmes.
    <br>
    <br>If an issue is so bad that it needs to be fixed before compiling, there’s no point in trying to come up with a decoration for it — just use #error so there’s no way it’ll compile. That’s how I remind myself what I was working on when I come in on Mondays.
    <br>

  24. Jim says:

    ok….i just ran across this posting. so…how do you know what it causing the BUGBUG? I have a machine that once you sign in, it pops up a message box: BUGBUG – Wrong Version. You have to click ok about 20 times for it to go away. No clue as to where it is coming from.