Pain is temporary, failure lasts forever

Lean, agile living for the running mother of Peter


What is a bug?

What is a bug? I had no idea this was such a delicate issue. The emotions involved while discussing the term can be overwhelming. In a previous project it had a practical reason: if something was declared a bug the development team was responsible for documentation and investigation. A bug was also given a higher priority than a change request of the same kind. So, the development team had an interest in declaring something not being a bug while the reporter had interest in declaring it a bug.

I've never found a definition I've liked. All that "not as designed" is so vague and imprecise that it means nothing. So, I've come up with my own definition. A bug as a by a user perceived malady while using a computer software. But, but, but,but if the malady is due to the user not turning on the computer, how can you classify that as a bug??? Well, the CAUSE of the bug may not be in the actual software: bugs can be found in knowledge, software, environment, processes and use cases. But the user doesn't care why. He sees a malady and for him it's a bug. And there should be a incident report on that. We have a not so satisfied customer, and we need to know that.

When I function as a product owner, it is important to keep track of all those bugs. If they are in knowledge, perhaps time should be spent on education. If the bug is due to process or usage, information concerning supported use should be improved or perhaps there is some nice business opportunity in the lacking process support. And if there is something sick in the code, perhaps we should fix that. Working agile and lean is focusing on the things with highest business value. And that does not mean coding in every instance.



Post a Comment

Subscribe to Post Comments [Atom]

<< Home