Expecting One Giant? Bring Five Stones
In Attitude 101, John Maxwell asks, “Why did [David] pick five stones for his sling on his way to encounter Goliath? There was only one giant. Choosing five stones seemed to be a flaw in his faith. Did he think he was going to miss and that he would have four more chances?” Maxwell continues, “Some time later I was reading in The Second Book of Samuel and I got the answer. Goliath had four sons, so that means there were five giants. In David’s reckoning, there was one stone per giant.”
Software developers and testers hunt giants too—bugs, that is. Like David, they should believe that where there is one giant, there are probably five nearby, and they should hope to find each one. Code errors can infect insidiously, silently, and in a disparate fashion, causing several bugs across the application. The software team should have an attitude of expectation that one bug is a glimpse into a room full of them. Instead of believing the job is done when one big bug is found, the team should think, “Now’s when the fun really starts.”
Depending on the activity of the code, sometimes there really is only one giant. But if the giant is lurking in an area where code changed, or the code is part of core functions, or the code executes a common function, chances are good that the giant has kinsmen. Related bugs need to be found because even if they result from the same code error, each bug may not be fixed by fixing that one error.
Perhaps you have code that doesn’t inherit as it should, so fixing a code error in one spot doesn’t resolve each bug. Finding related bugs may reveal architecture or logic problems surrounding the code error that caused the initial bug to appear.
When one giant is found, think like David. Use your tools with confidence to seek out other bugs. Assess what type of bug you’ve already found. Is it a run-time error, a logic error? Consider other situations where the application might perform similar functions or use similar data. Is there a race condition to take into account?
Software bugs are like roaches: Never assume there’s only one. Stepping on a roach that darts across your kitchen floor is just the beginning, right? You peek under cabinets, move furniture around, and sweep up crumbs and dust bunnies because one roach usually means more.
The more roaches you find, the more you understand what changes need to be made in the home to keep it free of those buggers. Similarly, software teams shouldn’t simply bag their first bug and go home; it’s the continued discovery of that bug’s relatives that leads to really improving the application.
