| Date: | April 26, 2006 / year-entry #147 |
| Tags: | no-good-deed-goes-unpunished;other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060426-19/?p=31393 |
| 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 bug 12345. While that may very well have been the case, bug 12345 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)
Comments are closed. |
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.
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 :-).
Just do what Open Source devs do when they get the hump and set it to WONTFIX. REASON = Tester is an idiot.
Ha! Ha! Ha! This is funny!
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 billg@microsoft.com 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.
"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"
"Give a man a fish…"
That’s the idea! Set up an alter-ego that only speaks Swiss but programs in Dutch!
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?
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.
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.
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.
-Wang-Lo.
Okay, Wang-Lo, while that joke may have been funny the first time, the second and third times it’s kind of tired…
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.
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… :-)
Oh, and thanks for reminding me why I LIKE working for a small company with 5-6 devs….
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.
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 :)
If all the above suggestions fail – you will just have to say "oh no you mean the <a href="http://blogs.msdn.com/oldnewthing/archive/2006/04/13/575742.aspx">other Raymond Chen</a>".
PS:Sorry, but I chuckled at Wang-Lo’s comment :)
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 billg@microsoft.com 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 ^^
get a psuedonym… …its standard procedure for public perfromers… What psuedonym would you choose and why? Something with latin or swedish origins?
…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."
"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.
-Wang-Lo.
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.
Raymond writes about getting stuck with a bug because he had once re-assigned the bug to another developer (the tar-baby…
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.
Provide it as a learning experience on interacting with the testers.
Raymond Chen in one of his posts&nbsp;jokingly wished that if he could use an alter-ego to update bugs…
That Outlook/Exchange bug.