Depending on the personality of the players involved, this sort of hand-off between teams usually takes one of two forms:
- Working with Pros - The largest percentage of the time, all parties act professionally. The engineer transferring the bug is sensitive to telling another team that there is a problem in their code. So that engineer typically does enough problem diagnosis to at least make sure that their software isn't at fault before initiating the transfer. It is no fun to tell someone else that they have a problem in their code and then subsequently find out that the problem was actually in your code.
- PITAs - A very small number of engineers are either so arrogant or lazy that they simply don't do the required level of analysis and just pass it along downstream for someone else to look at. The problem couldn't be in their stuff and their time is more valuable than yours, so they just transfer it. If you are on the receiving end of someone like that, it gets old in a hurry - you end up having to do their debugging and prove that the problem is not in your code.
I have recently discovered a third classification - people who just make shit up.
The old component that I worked on through last August is now owned by my colleague Wes. We talk a lot since I worked on that component from the ground up for four years and it is a non-trivial component in complexity, and there are areas of the component that are entirely new to Wes. So often times, he will consult with me on design issues or bugs that he is trying to fix. He is a very thorough and professional engineer and he always does his research and respects my time as well, so that is all good.
Wes came to me today with a question about a bug that had been transferred to him. The bug report indicated that my old component wasn't handling some input passed to it correctly. The function in question was just the ability to launch the installer UI on a particular package file. Now this function had been added back in 2007 and has been tested thoroughly by a dozen or so teams and had been in code shipping to customers since late 2007 and had been tested on different OSes. But Wes hadn't had occasion to dig into that part of the software, so we talked about it for a bit.
Once we had discussed this for a bit, it sounded like the software calling my old component was passing a malformed file path that looked like a combination of Windows and Linux style separators. Garbage in and garbage out. That should have been the end of it - we just needed to transfer it back to the originating team and tell them to debug their software better before calling my baby ugly.
But there was an interesting twist. In the remarks of the bug report, the originating team supplied this gem when transferring the defect to us:
This is a StringBuffer overflow.So it isn't bad enough that the originating team didn't actually debug an obvious problem that was in their software. It isn't bad enough that by simply looking at the stacktrace, that problem would be so bloody obvious, that they wouldn't have wasted our time. No, instead they throw this StringBuffer overflow crap out there. I was LMAO all night.
String Buffer Overflows are real and have been used to exploit many security vulnerabilities in OSes. Java is one of the few platforms that are not vulnerable to String Buffer Overflows (assuming you don't invoke native methods). But it was just the chutzpah of making crap up and making that assertion and then never even backing it up with any diagnostic information.
So now I have a favorite response for Wes when he asks me if I understand what is causing some problem in my old software. When I have no idea, I just tell him that "It must be a String Buffer Overflow.
