Email tip: I don’t have my bug numbers memorized

Date:August 8, 2007 / year-entry #290
Orig Link:
Comments:    38
Summary:Far too often I'll get email like this: From: X Subject: 27183 Have you started looking at this one yet? It may surprise you to learn that I do not memorize all my bug numbers. Please include a brief description of the bug in your message so I have a clue what you're talking about....

Far too often I'll get email like this:

From: X
Subject: 27183
Have you started looking at this one yet?

It may surprise you to learn that I do not memorize all my bug numbers. Please include a brief description of the bug in your message so I have a clue what you're talking about. The bug title is a good start.

It's like going to a doctor and asking, "What's your opinion on patient 1732?" You'll probably get a better response if you ask, "What's your opinion on Mr. Jenkins, the one in A113 who hit his head on the sidewalk?"

Addendum (since I know people are going to bring it up): Inside Microsoft, many teams use the defect tracking system to track things other than, well, defects. For those teams, it would more properly be called a "things that will require time" database. Records in the database might be bugs. They might be feature requests. They might be work items. They might be requests for collaboration from customers. I was once on a team that used the defect tracking system to keep track of vacations! Using the defect tracking system to record everything that consumes an employee's time means that you can generate a "How many days of work remain?" report to get a rough idea of how you're doing on your schedule.

Even teams that use the defect tracking system purely for tracking defects will usually have entries for things that aren't defects. For example, a defect report typically goes into the defect tracking system as soon as the report is received, before it is confirmed to be an actual bug.

Some teams maintain two databases, one for "potential bugs" and another for "actual bugs" and transfer records to the second database only after the bug has been confirmed. To me, this just seems like a bunch of work for no real benefit. Well, okay, they get brag about their low bug count since they make it hard to get something into the bug database in the first place. (This strikes me as just playing games with numbers.)

Addendum 2: I've been told that these useless email subjects are exacerbated by our defect tracking system. When you highlight a record and pick Send Mail, it generates a message whose subject line is... just the record number. Worse, the mail window is modal, so you can't go back to the record and copy/paste text out of it. At least that's what I've been told; I never use the Send Mail option, so I don't know what it does.

Comments (38)
  1. oliver says:

    May I ask what defect tracking system you use (if you don’t use a self-built system)? Where I work there are attempts to switch to "a new bug tracker", so I’m somewhat interested in what systems are successfully used somewhere else.

  2. Ian G says:

    I used to have conference calls like this where the report from the other end of the phone typically went "72345, fixed. 82345, fixed pending review. 123150, hope to check-in today." And given it was a call because the other participants where in different countries there was often a fairly heavy accent on top. Didn’t help understanding as the chairman apparently did have all the numbers memorize (or at least never asked about them!) and would rapidly move onto the next person.

  3. Alex Cohn says:

    The same thing happens if one sends a Word document from inside MS Word. I found the only reasonable workaround to be – save the mail at this point (luckily, Save works), switch to Outlook, and complete editing the saved mail item.

  4. Me says:

    Surely the bug will still be in the defect tracking system. Why don’t you just look the number up.

  5. BryanK says:

    The same thing happens (well, sort of) if you right-click a file in Explorer and hit "send to" -> "mail recipient".  I should note, however, that the dialog is not modal inside Explorer, it’s only modal in Outlook.  So you can go browse other files for a while, you just can’t go look up older email from the user you want to send the file to.

    (I suspect it’s something to do with MAPI, but frankly, it doesn’t hurt enough to care about finding the root cause.)

    Oh — this is old software, too, so maybe this particular modal-window has been changed by now.  (Win2k and outlook XP.)

    (OTOH, none of this really matters, either, as it’s OT…)

    Would it help to have a URL to the bug in these emails?  (… I suppose it wouldn’t if this bug-tracking system wasn’t web-based.  Duh.)  Anything I’ve used has been web-based, and all the automatic emails have had the URL to the bug in them somewhere.  (Of course, I’ve only used Trac and Bugzilla, so that’s not a huge sample, either.)

    If this was a manual mail, then I’m sure the user probably didn’t take the time to go look up the bug’s URL, let alone copy/paste it.  But depending on the bug system, the bug may not be too hard to find either — e.g. Trac uses URLs like http://<site>/<optional path>/ticket/<bug-number>, which isn’t terribly difficult to type in by hand once you memorize the starting part of the path.

    (And again, non-web-based bug systems can’t do anything like this…)

  6. Trevel says:

    Running through the list of numbers works as long as the agenda includes a list of the numbers and their description. Then it’s simply using the actual number instead of "item 5".

    If that note wasn’t attached to the meeting, though, don’t expect anyone to know what the numbers mean.

    It is astonishing to use a bug tracking system that sends emails that do not contain either a description of the problem they relate to or a link to the problem record, but I do. I hate it SO MUCH.

  7. Lisa Smith says:


    That’s what I usually do. It saves me having to remember lots of bug numbers.

  8. Barry Tannenbaum says:

    RE: Just look up the number

    But that’s not the point.  The person who’s asking the question could take the extra seconds to give a little context in their EMail message.  Even if you had memorized all of the bug numbers, the extra context helps with the recall of exactly which bug this is.

    EMail is already an interruption.  If there’s enough information to make me recall the issue, I might respond immediately.  If the sender expects me to drop everything and look up the bug number, they’re sadly mistaken.  Their message will go to the back of my queue.  My time is valuable too, and I’m probably deep in the middle of a debugging or coding session.  

  9. poochner says:

    I once had to do a telephony integration with a support system which created bugs / incidents and assigned them numbers.  The client wanted the number spoken to the caller. Simple enough, right?  However, the support system’s Windows client for the desk agents didn’t have a facility for looking up incidents by incident number.  We (the integrator / consultants) had to write a custom search in the support db for this.  Now THAT’S stupid.

  10. Mike Schwartz says:

    I just wanted to say I loved the A113 reference!

  11. jeffdav says:

    Yeah, that always annoyed me too.  The best part is the people sending these mails are usually bean counters who have no idea what you’re actually working on (see

  12. CDarklock says:

    Most people don’t understand how or if your job is different from theirs.

    When you deal with the same small group of bugs all day, you have a neat little list of twenty or thirty bugs that you can scroll through easily. And for a lot of people, that’s their job. They go in and out of meetings, check the status of bugs, and every once in a while need to ping someone about the bugs that aren’t being updated.

    When you write actual production code, bugs are something you deal with on three occasions: when your manager has outright ordered you to work on them, when your normal work runs headlong into the bug in question, or when you have nothing better to do. That last occasion never arises. So you don’t have a list of twenty-odd bugs you’ve read every day for the past month. You’ve got a list of some two hundred bugs you haven’t reviewed in weeks. Indeed, the last time you really looked at it was when we did the ZBB three months ago, so every bug on the list is completely new to you.

    IMO, the person sending the mail should be exerting the effort to make it effective. (That’s not selfish, because I tend to be the guy with the list of twenty bugs.) When you write a lazy email, you’re effectively saying "hey, YOU do the work here".

    As far as email being an interruption, close your email client. I love email. Don’t IM me. Don’t call me on the phone. Send me email, which I can read when I’m damn good and ready.

  13. JenK says:

    One advantage to using a web client for the bug tracker is being able to include the URL.  Yes, the recipient still has to open the page, but at least it’s a link.  

  14. David Walker says:

    Since you brought it up, Raymond, a complaint that is sometimes lodged against (some) doctors is that they will ask one another questions like "What do you think about the appendix (or heart attack) in room 301?" and they might not even know the patient’s name… or realize that the patient HAS a name.

    Some medical schools are trying to train new doctors way from this mode of thought.

  15. Steve says:

    Actually, my team wrote the bug tracking software that Raymond (and most of Microsoft) is using and I actually wrote that Send Mail feature. That was something like 6 years ago so my memory is hazy but the issue was that the Simple MAPI calls that we used to create the e-mail take a parent window handle that the MAPI engine causes to go modal for the duration of the compose call. The other limitation is that the mail message is always generated in plaintext – no RTF/HTML option.

    However although a few people complained about this, it didn’t appear to bother enough people to warrant spending time fixing this. And the fix would have involved writing reams more code that would be worth while.

  16. Ben Cooke says:

    It is a pet peeve of mine when people write email messages where the body refers back to the subject. Usually by the time I’m reading the body I’ve already filed the subject away in my sub-concious or purged it from my mind altogether, so when I get a message like the following I often spend precious cycles wondering what on earth the author was talking about:

    Subject: The widget-tracking system

    Hi Ben,

    What is the status of the above?

    Love Mr Customer

    Invariably my first thought apon reading that is that the customer wants to know the status of my name, or something.

  17. Mikkin says:

    A support center I use sends an acknowledgement like:  "Your request has been logged as work order number XXXXXX.  So that we may serve you better, please be certain to reference this work order number in the subject of all correspondence on this matter," or words to that effect.  The subject of the acknowledgement itself does not reference the work order number.  D’oh!

    Re. addendum 2:  Worse still, send-as-email-attachment using Outlook from some applications makes the email window modal with respect to both the application and Outlook.  Since I can’t access the document or the prior correspondence, I only use send-as for a naked (without cover) document.

  18. schwiet says:

    "However although a few people complained about this, it didn’t appear to bother enough people to warrant spending time fixing this."

    Fixed, 997859

    Raymond just curious, what is the index value at for new raid items in Vista SP1?

  19. Ralph says:

    Remedy? Action Request System?

    I hate it too.

  20. David Brooks says:

    "And the fix would have involved writing reams more code that would be worth while."

    What about be the fix that just puts the title field into the email subject line?

    "Would it help to have a URL to the bug in these emails?"

    Actually, in the system most of us are thinking of, there is a query attached that will open the bug in the tracking system. But the other objections (it’s a stacked interruption; you may not be on the corporate network) still apply.

  21. Josh says:


    Given that it’s been around for 6 years, and will likely be around for that much more, it would seem that the "reams of code" required to put in the bug title instead of the bug id in the email would’ve saved 15k developers 15-30 seconds each time at least once a week for 6 years. :)

    Sorry, had to vent. So many problems with X that aren’t ever going to get fixed…

  22. Mr. Capsule says:

    Raymond has mentioned A113 before – the following is where I first read about it:

  23. Anony Moose says:

    Well, it’s obvious.  Just enter your vacation in the defect tracking system, and ask permission to work on the appropriate item number.  Who could refuse?

    Well, either that or vacations are a defect that management wants stamped out.  ;)

    (It had to be said.)

  24. Ulrich says:

    Nice to know that this is an international and cross-company problem.  

    I used to blame it on the "bean-counters" as well because that’s where I encountered it first (and there are still people who only care about "another item closed").

    But later I learned that in some cases this just has to do with how people think: I have some colleagues who somehow in their brain index the problems by bug number. They will know the description of the bug but think about it by number. So, while I think about "the bug where foo…" they just think about bug 12345, but  can give the details about the bug. So I just learned to include the bug number when I send mail them about a problem I try to train (somewhat successfully) them to include a short description when they mail me.


  25. David Walker says:

    Not to make this into too much of a digression, but maybe doctors shouldn’t discuss cases in the hallway.  They certainly CAN refer to people by name if they are consulting with each other in a private place.  The "whether other people can overhear" part is what’s important.

    On the flip side, the last time I was at my dentist’s office, I heard the assistant loudly ask a patient in another room whether he (or she) was still on medications X, Y, and Z.  I could determine quite a bit about the patient’s condition from the fact that I knew what medications X, Y, and Z were used for.  I suggested to the dentist that he should teach his staff another method.

    On the third hand, some companies overreact to the HIPAA laws.  I had one company tell me "The HIPAA laws don’t allow us to do such-and-such", when the regulations don’t say that at all.  (I have actually read most of the regulations that have been written as a result of HIPAA.)  They meant to say "in our overreaction to HIPAA, our company policy says we can’t do such-and-such".

  26. "Surely the bug will still be in the defect tracking system. Why don’t you just look the number up."

    Ignoring the extra time needed, especially for the occasional times(*cough*) that the server is slow, there are many cases where you’re on email and could otherwise comment on the bug, but you’re not connected to the internal network so you can’t look it up.

    This is one of my pet peeves, as it takes near-zero extra effort from the person sending the email to also include the title of the bug.

  27. Ry Jones says:

    Considering RAID was retired years ago, the request:

    "Raymond just curious, what is the index value at for new raid items in Vista SP1?"

    has a null answer. If you want to know the status of internal items like this, get a job on the team. Most of Microsoft is hiring. Don’t ask Raymond to release this information.

    If you’re internal, there’s a tool that lets you create links for bug numbers. It’s quite nice; I always linked my bug numbers via this tool when sending email.

    The alternative is attaching multiple query files, and that’s not much of an alternative.

  28. Mr Cranky says:

    The real WTF is somebody is sending emails requesting status on items in a tracking database.  

    Isn’t that the purpose of the tracking database?

    On the other hand, the one used at my job is so hideously awful nobody really "uses" it except as required by policy & procedure.

  29. Yeah says:

    I hate TestTrack, too.  Why the hell are those dialogs modal???

  30. Leo Davidson says:

    Too many systems are like this. A couple of months ago I received this email ("WXYZ" used instead of the real system name):


    This Mail has been sent to you because we have recorded a WXYZ SMTP Request For Response transaction against your name.

    If this is not the case, respond to this mail stating your full name and contact number.

    ===== Response to Request =====

    Progress Record for Incident 1234567 Was Successfully Added

    =====   End of Response   =====

    ** This Mail Generated Automatically by the WXYZ SMTP Module **


    Being unsure of the reason for the mail, and unsure of whether I should even care, I sent this back to the WXYZ team:


    I think the automated emails similar to the one quoted [above] could do with some improvement and clarification.

    Please take this as constructive suggestions on how to make the email better. I’m not just trying to have a go. :)

    I don’t know what a "WXYZ SMTP Request for Response transaction" is, let alone whether one being recorded against my name means I have to do something or not. (I know what WXYZ, SMTP, transactions, requests and responses are but I don’t know what that combination of words means.)

    Also, for people who don’t memorise the issue numbers that correspond to all the WXYZ requests they may be involved with, it would be good if the email included the summary/description of the issue as well as the issue number. (Or two issue numbers? There’s one number in the subject and a different number in the "Response to Request" section in the email. I don’t know the meaning of either.)

    All the email tells me is that an event of some sort was created in a system that I don’t know or care much about. It’s easy enough for me to delete the email and get on with my day but if it’s supposed to contain useful information, or I am supposed to do something in response to the information, then it isn’t clear at all. If it isn’t supposed to contain useful information then I don’t need it in my mailbox in the first place.


  31. borlock says:

    Do you really care whether the doctor knows your name? Or think of you as anything more than a case?

    Most people I know would rather be treated by Dr. House than Dr. Grey.

  32. Adam says:

    Regarding doctors,

    I am hip deep in healthcare and one of the recent laws (HIPAA) requires that no patient identifiable information be discussed where other people can here it.  

    So, it would not be "legal" to say "What’s your opinion on Mr. Jenkins, the one in A113 who hit his head on the sidewalk?" in public, while it is ok to ask "What’s your opinion on patient 1732?" because the person who overhears you does not know who 1732 is, or what happened to them.*

    That is an extreme example, but using a patients name and saying what they are in for is a no-no in a public place, just file it under that "strange but true" heading.

    * This is according to the videos we had to teach us about hipaa when it first went into effect, it is not legal advice.

  33. Anon says:

    "Raymond has mentioned A113 before – the following is where I first read about it:;

    It’s much older than that I think

    And weird to read this – the place I work now has a bug tracking system written in house that has all the same problems. Mails have unhelful subjects but the worst thing is it spams people with an autogenerated email for every event on any bug report in the project you’re working on. It’s written in Java too, so it takes several minutes to start up.

  34. Stephen Jones says:

    The fun is that Word uses the title that is in the Properties Box. It’s quite common for people to take a Word document they have written, write over it and then save under a new name. However the title and all other details in the Properties Box stay as they were in the old message.

    As a result of this one of my colleagues send a memo to his managers with the title in Outlook being "Happy Birthday, darling."

  35. Tomer Chachamu says:

    Funnily enough, we also bought a system at my new workplace that does the same thing, repeatedly. Ugh.

  36. RonO says:

    @Anony Moose

    "Well, it’s obvious.  Just enter your vacation in the defect tracking system, and ask permission to work on the appropriate item number.  Who could refuse?"

    And if you’re working a defect like this, are you really taking vacation?  After all, working a defect means billable hours.  That’s the nice example of getting paid to do nothing*!

    * Obviously you’ll do something while on vacation, even if it’s just lying there breathing.

  37. william says:

    Yeah, that old modal message window in Outlook. Hit ESC, hit "Yes" when it asks you if you want to save, double-click on it on your inbox. It’s not elegant but it works. Not sure why anyone thought modal message windows were a good idea…

  38. microbe says:

    It’s really easy to find the full bug from the number, isn’t it?

    Or you suggest he send you a full attachment of the actual bug which you could easily find anyway?

    [(1) Try looking up a bug from home. (2) In which case, I guess you won’t mind if my email to you consists of an URL that you can type into the address bar of your favorite Web browser. It’s really easy to visit a Web page given the URL, isn’t it? -Raymond]

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index