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.

SayNoToBugging

(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

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

“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.

To sum up, quoting from a talk by Dr. Ackoff (which is dubbed if Dr. Ackoff had given a TED talk and is a must watch for anyone interested in Systems Thinking) says about removing bugs:

“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”?

Tags: , ,

3 responses to “Say No to “Bugging””

  1. rumadak says :

    informative!!
    wrt Ye-bugging, won’t proper check-in’s (svn etc.) help you figure out whose code broke the functionality!!

    Liked by 1 person

Trackbacks / Pingbacks

  1. Reading Recommendations # 25 | Adventures in QA - July 15, 2015

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s