Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

What is a BUGBUG?

What is a BUGBUG?

  • Comments 27
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.

  • 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.
  • 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!)
  • 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 ;-)
  • 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.
  • 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.

  • 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 :)
  • C:\WINDOWS\INF\mshdc.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 ^_^
  • Once upon a time (maybe still?), the Photoshop team called these "Bullshits". As in:

    //BULLSHIT: this should be calculated at runtime, not constant
  • 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...
  • !! 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.
  • 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...
  • 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.
  • Martin: By writing
    real_boolean = (sort_of_boolean != 0) ?
  • 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);


  • In many open source projects I've seen the FIXME marker instead.
Page 1 of 2 (27 items) 12