Say No to “Bugging”
In one of his classical pieces “The Art of bugging: or Where Do Bugs come from”, Jerry Weinberg suggests that if debugging is the process of removing bugs then bugging should be the process of putting those bugs in. He then list down a set of bugging possibilities in his typical funtastic way.
Taking his thought further, I think that a Tester’s job should not be just find bugs (and humiliate Programmers) rather one of the prime jobs of a Tester is to improve quality in whatever way. Other testers have suggested some ways and I think helping team adapt a policy of no “Bugging” can be a game changer too.
(the original picture is here: http://pictures-e2.thumbtackstatic.com/pictures/911/c7ux0jzhx0mh3a97_580x380.jpg )
Taking Jerry’s examples, I have picked two types i.e. Gee-bugging and Ye-bugging. Let’s see what they are and how to tackle them.
“Gee-bugging is grafting of bugs into a program as part of a piece of “gee-whiz” coding—fancy frills that are there to impress the maintenance programmers rather than meet the specifications.”
There are many ways to avoid this. One is to help Programmers become experienced one in light of this blog which outlines responsibilities of the senior developer. One of the line says:
“A senior developer will understand that this job is to provide solutions to problems, not write code. Because of that, a senior developer will always think of what they are doing in terms of how much value it brings to their organization and their clients vs how much effort they are putting in.”
So we have to make our Programmers experienced in providing solutions and not writing beautiful code. Peer code reviews can help and practicing Three Amigos will help Programmers understand the complexity of the client world and devise solutions for them.
“Ye-bugging is a mysterious process by which bugs appear in code touched by too many hands. Nobody knows much about ye-bugging because every time you ask how some bug got into the code, every programmer claims somebody else did it.”
In the modern world teams are really distributed and code bases are shared. This can really become a problem unless we implement a world class configuration system that works on Continuous Integration principles. Such that code written by any one is complied continuously.
In our team we have a build process called firebug in which code builds every few hours. Any one who has committed code between two firebug jobs, get an email on successful or unsuccessful build. In this way, a really mixed up code is maintained without any problems.
“By removing what you don’t want, you don’t necessarily get what you want”
So let’s work with our teams and say No to “Bugging” and build what we want.
What other practices you suggest to end “bugging”?