Bugs and Change Requests

As developers, dealing with bugs, issues, and change requests is part of our jobs, whether we like it or not. But one thing that those who report such things to us can get wrong, is correctly classifying the information. And this can be a problem.

For me, a bug means one thing, something is wrong with the delivered code, be it a website’s backend or frontend, and it needs to be identified and fixed.

Change requests however, are something different. These are things that are new and additional to what was delivered, things that you cannot have known about and therefore did’t deliver them initially.

I take bugs personally.

When someone reports a bug, I am annoyed. Annoyed that what I delivered was substandard. Annoyed that there was a problem with it, something I missed.

This is irritating.

A change request, however, is something new, something that the customer has decided that they want in addition to what I have delivered. This is ok. Let’s talk about the feature and start working on it.

But mixing up the two, i.e. reporting a change request as a bug (the opposite is less likely to happen), drives me crazy, as I feel that the person reporting it, be it a project manager or the customer, thinks that what was delivered is wrong in some way, because it doesn’t contain this new thing that they never told me about.

Initially, because it’s reported as a bug, I will take it personally, as mentioned above. But it’s not my fault. It’s not the customer’s fault either, it’s just not a bug, it’s a change request.

So, I say to those of you who send bug reports and change requests to developers, take some extra time to ensure that you have indeed classified it correctly before you pass on the information.

It’ll help a lot more than you know.