No good deed goes unpunished: Bug assignment

Date:April 26, 2006 / year-entry #147
Orig Link:
Comments:    36
Summary:Sometimes you're better off keeping your fool mouth shut. The other day I got a piece of email requesting that I look at a crashed system because the tester believed it was another instance of bug12345. While that may very well have been the case, bug12345 was a kernel pool corruption bug in the object...

Sometimes you're better off keeping your fool mouth shut.

The other day I got a piece of email requesting that I look at a crashed system because the tester believed it was another instance of bug 12345. While that may very well have been the case, bug 12345 was a kernel pool corruption bug in the object manager, something of which I know next to nothing.

Why was I being asked to look at the machine? Because the bug was originally assigned to my team. As a gesture of good will, I reassigned the bug to a more appropriate team, and that was my downfall, because that put my fingerprint on the bug report. The second occurence of the bug was inside another component entirely, still completely unrelated to my team. But the tester thinks that I am somehow responsible for fixing the bug since my name is now in the bug report.

Perhaps I need an alter ego whose name I can use for cases like this, where my involvement in a bug is not as an interested party, but rather as somebody merely offering to help redirect the bug to the correct developer. But that merely defers the problem: What should I do if somebody asks the alter ego to investigate the bug?

Comments (36)
  1. richard says:

    This is the problem with associating your name with a problem. Most people are smart, they remain anonymous, on the other hand, I always clearly document what I’ve done. So, months or years after I’ve been in a piece of code, because my "fingerprints" are on it I get called in to explain changes someone else made after me.

  2. Sometimes Microsoft is better off not hiring damn fools who think that assisting placement of bug ownership makes you personally responsible. Get that tester reassigned to typing pool issues rather than kernel pool corruption :-).

  3. Day Barr says:

    What should I do if somebody asks the alter ego to investigate the bug?

    Set up a mailbox for your alter ego, with an autoresponse containing a step by step guide to finding the owner of a bug.  Include pictures.  And maybe a powerpoint presentation.

  4. Moi says:

    Just do what Open Source devs do when they get the hump and set it to WONTFIX. REASON = Tester is an idiot.

  5. g says:

    Ha! Ha! Ha! This is funny!

  6. andy says:

    What should I do if somebody asks the alter ego to investigate the bug?

    Your alter ego should reassign the bug to the real mr. Chen then, and hopefully the bug is squashed, nobody understands why your alter ego reassigned the bug to the real mr. Chen and everybody should be happy :)

  7. Peter Ritchie says:

    Sometimes Microsoft is better off not hiring

    >damn fools who think that assisting placement

    >of bug ownership makes you

    >personally responsible.

    Perfect employees, testers included, are hard to come by.  In an effort for a company to make money, they hire who they can and try to get a product out.

    With 60 000 employees you’re bound to not be able to have all of them "perfect", what ever "perfect" means.

  8. Steve Monk says:

    Raymond, I have two potential solutions for you:

    1) Setup your alter ego so that you can use him to re-assign bug reports, but for all other purposes it looks like he has left the company.

    2) Use as your alter ego.  Is somebody really going to ask him to fix a bug?  And even if they do, there’s a whole team of people reading his email, so one of them can forward it to the right person.

    Please let us know which you choose.

  9. x says:

    "What should I do if somebody asks the alter ego to investigate the bug?"

    It is unlikely that that will happen if you name the alter ego "B. Gates"

  10. Dennis says:

    As a gesture of good will, I reassigned the bug to a more appropriate team

    That’s the real problem. Always send the bug back to the tester and ask him/her to send it to the right team.

  11. John Schulze says:

    That’s the real problem. Always send the bug back to the tester and ask him/her to send it to the right team.

    Egg-zaktly. Unless the tester gets feedback that she screwed up, she’ll keep doing so.

    Now her wrong impression that you handle these bugs will be reinforced, because you did indeed handle it.

    And why do I say "she"? Because the women around here can’t seem to be able to route a damn bug to save their collective lives. None of the guys have problems.

  12. Michael C. says:

    "Give a man a fish…"

  13. Puckdropper says:

    That’s the idea!  Set up an alter-ego that only speaks Swiss but programs in Dutch!

  14. Don says:

    This is a problem I face at my job also.  

    Part of the problem at our company is that the Level 1 personnel have limited interaction with Level 2 groups or above which gives them a limited knowledge of who does what.  In our organization there are a small # of Level 1 groups and part of their job is assigning tickets to different level 2 groups.   Each Level 1 group typically only hands out tickets to a few Level 2 groups.  The problem is when they get a ticket that is supposed to go to a group that they normally do not hand out tickets to.  

    I have had too many experiences like Raymond where my name gets on a ticket and a few days or weeks later someone is wondering what my involvement in the issue was.  So this is what I do if the ticket ends up in my queue. I will often call 1st Level support, give them the ticket # and tell them what group they need to send the ticket to.  This solves two things: 1) The ticket gets to the right place 2) my name never ends up in the work log.  

    Another problem I run into in our organization is that level 2 support do not like getting tickets redirected to them from other level 2 employees (from a completely different group). I guess they figure that the admin who handed off the ticket is just trying to get out work, when really they are just trying to get the ticket to the right department.  What ensues from there is a ticket that gets passed around from group to group with no one taking responsibility for it.  This will quickly infuriate our internal customers which get an email each time the work log is updated.  Does anyone else have this problem?

  15. Alex says:

    The only suggestion I’ve seen that might help would be to assign the bug back to the tester, in order to force them to route it appropriately.  I don’t know why a simple explanation as to your role in this process isn’t sufficient, but we also have our share of process issues here.

  16. Just reassign.

    Raymond you complained too much:).

    For the last few years (and still happening today), all the advapi32 crashes are assigned to our team. And it is all because some point many years back in the past, one of the members in our team investigated one crash in advapi32.

  17. Wang-Lo says:

    Most guys — in general, there are exceptions — tend to think in terms of processes, while most girls — in general, there are exception — tend to think in terms of incidents.

    So if the egg-cooker is broken, a man’s first thought is, how can the egg-cooker be fixed, then how can it be kept from breaking again, then how can other things break in the same way, then how about a whitepaper on this failure class.  Meanwhile he gets salmonella from eating raw eggs.

    But a woman’s first thought is, how else can I get the eggs cooked, then how can I find the time to cook eggs without the egg-cooker tomorrow, then can we eat something that’s easier to cook than eggs now that the egg-cooker is broken, and don’t let the baby get at the raw eggs.  Never a thought to fixing the damn thing.

    Similarly, if a bug is reported to the wrong developer, a guy’s reaction would probably be, why was this sent to me, who should have sent it where, and how can I make bug reports go to the right developer.  But a girl’s reaction would be, this bug report is in the wrong place, how can I get it to the right place, and how can I best help this one bug to get fixed sooner.

    I hope you can see where I’m going with this.  Yes, Raymond, I’m afraid you route bug reports like a girl too.


  18. Okay, Wang-Lo, while that joke may have been funny the first time, the second and third times it’s kind of tired…

  19. It seems to me that when you reroute a bug to another group, you add a note. Is the tester ignoring a comment to the effect of "this isn’t our bug"?

    It’s best when it’s spelled out completely in plain English. On a previous assignment, my team used the convenient abbreviation NMD for "Not My Department" when we got misrouted bugs. Unfortunately, a manager interpreted this as "No More Developers" and thought we were passing bugs to his team because we couldn’t afford any more staff of our own. The ensuing meeting was far from forgettable.

  20. steveg says:

    At one job I was on a defect was raised against a tester: "John Smith completely useless". True, as it happened, but it wasn’t well received.

    I’d just add a comment saying "Code/component owned by TeamABC, reassign to them for resolution." And if it’s one of those persistant ones that keeps coming back, have a chat with the tester over the phone.

    And if that doesn’t help reassign it to a tester in a different team… :-)

  21. Jen Kilmer says:

    Oh, and thanks for reminding me why I LIKE working for a small company with 5-6 devs….

  22. Mike says:

    The thing that really drives me nuts is that the Windows group has an internal website to do full-text searches of the bug database.  Many bugs have very distinctive stack traces and it would take all of 30 seconds to do a quick search to see if the bug is already known but people just don’t do it.  They’d much rather divert the devs from fixing the bugs by sending them email paraphrased as "is this known?  Please do my job for me and lookup the bug number in the database and report it to my manager", or they file duplicate bug #37.  Or better yet file the dup *then* send email *then* demand the dev resolve the dup and *then* reject the resolution because a fix isn’t in thier particular branch yet.

  23. Jen Kilmer says:

    Probably the tester has no idea what’s going on and is hoping you can magic it away. A simple "The bug isn’t related to my area. A look at bug 12345 will show that I merely reassigned it to the APPROPRIATE team." *should* solve the problem.

    If not, well, appearing at their desk with your most abusive Deutsch should freak them sufficiently :)

  24. If all the above suggestions fail – you will just have to say "oh no you mean the <a href="">other Raymond Chen</a>".

    PS:Sorry, but I chuckled at Wang-Lo’s comment :)

  25. Norman Diamond says:

    Wednesday, April 26, 2006 10:25 PM by Troy Phillips

    > PS:Sorry, but I chuckled at Wang-Lo’s

    > comment :)

    Whew, I’m glad I wasn’t alone on that one ^^

    Next, I couldn’t help thinking that a certain complaint had all the appearance of someone being troubled by PMS.

    Wednesday, April 26, 2006 11:27 AM by Steve Monk

    > 2) Use as your alter ego.

    Oh no.  Now that that e-mail address has appeared in a blog, just think of all the spam he’s going to get.

    Meanwhile, surely testers would pin bugs on him without hesitation.  A billion customers do just that ^^

  26. ::Wendy:: says:

    get a psuedonym…  …its standard procedure for public perfromers…   What psuedonym would you choose and why?  Something with latin or swedish origins?

  27. Adam says:

    …or something with pig-latin and swedish-chef-bork-bork-bork origins.

    "Yes, this bug should be assigned to Orkbay Orkbay O’Onenay. He’s Irish you know."

  28. Wang-Lo says:

    "Okay, Wang-Lo, while that joke may have been funny the first time, the second and third times it’s kind of tired…"

    You’re right, I’ve pushed the bit way too far.  This is why I have remained a nerd all my life:  I never know when to stop.

    So, I apologize.  No more on this topic, I promise.


  29. AC says:

    Just do what some PMs do. Go to a team triage meeting and have "triage" reassign the bug. Then your name is never on it. Just make sure they don’t drop your name in the comments to it though.

  30. Raymond writes about getting stuck with a bug because he had once re-assigned the bug to another developer (the tar-baby…

  31. bug hunter says:

    I work on a bug triage team and we specifically never take ownership of a bug for that exact reason. Whoever has it, keeps it until we decide where it goes next. We add status or notes, but never own it.

  32. No flames please says:

    Provide it as a learning experience on interacting with the testers.

  33. Raymond Chen in one of his posts&amp;nbsp;jokingly wished that if he could use an alter-ego to update bugs…

  34. That Outlook/Exchange bug.

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