One of these days someone from my team told me about a story where someone closed a bug with the comment: “Works as coded!”. Well, its true, indeed, and its very difficult to discuss this argument. Probably his project manager will not disagree (I hope) with the comment but certainly will disagree by closing the “bug” with such argument!
Once in a while, I do training, I’m a Microsoft Certified Trainer and a Portuguese Certified to do training in any subject. (This doesn’t mean I can really do training to anyone in anything, its just means Portugal accept me to do training).
In one of these trainings I was teaching my students about software development cycle, and between roles, risk management, project management, etc.… one of the lessons was about bugs. What is a bug?
“A bug its nothing more than a problem in the development that its visible in the final product to the customer. “
You can disagree with this sentence, but think in it for while?
– Do you really could design all the possible tests (unit, functional, etc) in a way that you can guarantee that’s impossible your application/system has no bugs?
Lets dream (for a big application) you can! And you conclude that you need to develop about 2000 tests with 10000000 input states for these tests, and expect 190000 different outputs from these inputs. (for clarification, you must test success and probable/expected failures)
If you are developing, for instance a web site, and you know that from all these bugs, only 1/100 could be visible or could bring trouble (semantic and/or behavior) to your application, it means you will not have to correct all the other 9/100 bugs discovered. To your customer, its important to pay more development weeks to the team to correct these 9/100 bugs? And if the customer its your company, I will bet with you that the project manager doesn’t want these 9/100 bugs corrected! It will not increase any value to the final product, it will not have any visible impact to the final customer, the only think that will increase it’s the project expenses.
As a developer, as a team leader, and as a project manager, something that I learned it’s: Any technical think in a project must have a business impact, and the goal of a member of team, such as leader, developer or project manager its to minimize the expense and increase quality of the product. This quality is observable by the final customer and not from the developer team. I think, this is applied to any subject, not only software development.
In a future post, I will merge this bug concept with the complexity/complicated subject post I have wrote before, and we can really have some fun discuss this intersection subjects, since that, most of times, a really software bug its something about application behavior, and behavior its related with predictability, not related with understanding (at least in complex systems). Read my old post ”Complex or Complicated” and I think you will know what to expect from my future post.
In the future, be more nice with the bugs!