Allen Bauer has a cool post on reporting bugs and the common sense etiquette that should be used.

I hope folks understand that by following a few simple rules and creating a defect report that you would like to get is actually you contributing to your own success.  In this one case I have to say that karma is the best way to describe this process.  But paying it forward and actually becoming a part of the solution, it will all eventually come back to you.  Even though you may think your contribution is tiny and insignificant, the fact of the matter is that your contribution when compounded with everyone else’s can pay back in large dividends.

Having been on both ends of the defect report, I completely concur with Allen. A long time ago (and in a galaxy far away), I was moonlighted as the tech support “department” for a well known reporting package that used to be installed with Delphi. On average, I would get between 30 to 60 emails a day from other developers who bought this package. It never failed to amaze me how hard it would be to get people to send specific information to duplicate a badly worded or vague bug description. Mind you, this reporting package had plenty of issues to deal with, but many times I couldn’t duplicate the bug that was reported by the description that was included. I would usually send a followup email asking for the steps required to duplicate the bug.

I tried to avoid getting sent entire projects. This was 1997-2000, and I was doing support from a dialup account, it woul take forever to download everyone’s projects as they usually sent me everything, binary files included. Sometimes, I needed the full project to duplicate the problem. That part was always interesting, you learn that the users will use the code in ways that you did not expect. There were always a few people who would refuse to provide detailed information and I would get a ranting email about not wanting to peform QA work for free. I actually received an invoice from one guy for the “services” that he had provided in tracking down the problem. [more about that when I finally decide to blog about that job].

On the other end of the spectrum, I spent a considerable amount of time documenting flaws in Sybase’s ADO provider for Adaptive Server Anywhere. In the beginning, they wouldn’t take my bug reports seriously. They would tell me that it was a Delphi ADO issue and not a problem with their provider. The problems were not with Delphi or it’s ADO components, but they couldn’t duplicate the bugs from my descriptions and they were not inclined to look at Delphi source code. I ended up coding detailed examples as VBScript files. One of the nice things about ADO was that it behaved the same way no matter who it called it. With those examples, I was able to get Sybase to spend time tracking down the problems that I was having. They were never able to fix those problems, but I did appreciate their efforts. What came out of those examples was that I was using Sybase’s ADO provider in a different way than they were testing and apparently, their testing did not include all of the features supported by the provider.