Working with bugs

No, this is not a post on entymology; rather, it’s a bit of a lament on the lost art of filing bug reports. Though they may bestride the programming world like a colossus, even the best programmers will eventually leave bugs in their code. Sooner or later, some poor user will fall foul of it.

You then have a number of solutions, depending on where the product came from. For a commercial product, you can:

1. ignore it and hope it goes away;
2. file a bug report, and hope that the provider will fix it;
3. find some sort of workaround, or just learn to live with it;
4. vote with your wallet, and switch to a competitor’s product

For an open-source product,, you have an extra option:

1. download the source code, and fix it yourself, and preferably submitting your fix back to the community.

In my case, it was a bug in a Microsoft development tool, the succinctly named Microsoft Visual Studio Team System 2008 Database Edition GDR R2. As an aside, let me say that I’ve been using it for all of 2 days, and I absolutely love its functionality. It finally makes versioning and deploying databases a delight rather than a painful chore. There is now no excuse for organisations not to have their databases under version control, or for having painful manual deployment processes.

Anyway, it has a bug in it which is holding up a particular project at work. I searched for a solution, and found someone who had reported the same issue some 9 months ago. Unfortunately the bug report that they filed was so lacking of information that Microsoft promptly closed the bug as Not Reproducible. In fact, it’s not 100% certain that the bug relates to my issue because it is so light on details – it just reports the same error message.

As it happens, the steps required to reproduce the bug were incredibly trivial, so I opened a new bug, and gave the sort of details that a developer trying to fix a bug needs to see – in other words, I described what I was doing, what I expected to see happening, and what actually was happening. More to the point, I list the steps that the developer should take to make the same thing happen for them.

The first step to being able to resolve a bug is to be able to reproduce it. If you can’t reproduce it, how can you work out what is going wrong, and how can you prove that you’ve fixed the bug? And if the bug reporter doesn’t tell you how to reproduce the bug, what chance do you have of being able to fix it?

So please – if you want your bug to be fixed, consider the poor developer who has to fix it, and tell them what they need to know to get the job done. Anything less, and you’ll have a 9 month wait before someone else with the same problem files the same issue again.