DREWspective

• Not done
• Not working
• No changes made
• Not fixed

I’m racking my brain as I write, but I can’t think of a single other "bug report" that gets on my thickwick more than the above. And now you’re going to find out why.

First of all, whether you’re a web developer, programmer or someone who works on some kind of long-term project, you’ve probably come across some guidelines for submitting "bugs", or as I prefer to call them, tickets.

("Bugs" always imply that something is wrong, and in recent times I’ve heard the term being used for feature requests and tweaks.)

Unfortunately, you may have been in a company, or "team", where the policy is to make these "bugs" as vague and nondescript as possible. I’ve been in three such places to date.

On several occasions I’ve been presented with a "bug" that looked something like this:

012345: product price not showing

not working - pls fix

and every time I’ve wanted to retort with

please be more vague

but I can’t do that, because I’ve been brought up on "cynical" comments already. That’s how serious this is.

So what is the problem?

The first thing is, you may have already addressed the issue at hand, whether you’re working on it or you’ve done the work. You might have spent valuable time and energy implementing a solution. But because the other person can’t see the result, they automatically decide that it hasn’t been done, rather than double-checking on their end for anything that could hinder progress.

I remember one good example from when I was relatively new to permanent work. The company had decided to use some (what was then) esoteric method of updating a site, where I would edit a file and then have to copy it using Dreamweaver to somewhere else, where another developer would do some more work on it.

Well, I had made the necessary updates to the pages, and to the best of my knowledge had followed the instructions. The next morning I received an e-mail basically telling me that none of the updates had been done, followed by a written tongue-lashing. And if that wasn’t enough, the Technical Director joined in soon after and had a dig at me as well.

That was an extreme case, which ultimately hammered the final nail in the coffin and resulted in my resignation. That’s an example of what can happen when people get lazy and make assumptions.

The second thing is, a "bug report" like "not done", "not working" etc. gives you next to no information. You don’t know what exactly is not working, what kind of problem it is, or whether it is actually working instead.  You end up wasting valuable time asking questions and gleaning information, or—worse yet—try to figure out what the problem is yourself. I’ve been in at least one company where they insisted I asked questions, but threw things right back at me (on occasion) when I did.

These kinds of statements are controlling; as long as you don’t know what the real issue is, they are controlling you. It must be handled appropriately, and if they refuse to help you, leave.