Douglas Adams, muse to software developers everywhere, had this to say about bugs:
"Just as a slow series of clicks when speeded up will lose the definition of each individual click and gradually take on the quality of a sustained and rising tone, so a series of individual impressions here took on the quality of a sustained emotion[.]"
Ok, yeah - the quote is really from "Life, the Universe, and Everything", and he wasn't talking about bugs, but he could have been.
If you look at bugs one at a time, you can miss some important "big picture" stuff. It's possible to spot product design issues, usability issues, architecture issues, and more by looking at patterns across multiple bugs. Instead of just taking the bug at face value, consider whether there are other factors that caused this bug (and others like it) to show up. Unless you're writing mission support modules for NASA, it doesn't make sense to do a full five-why's breakdown on each bug, but keep your eyes open for signs like this:
- You find yourself going back to the same area of code over and over.
- User complaints cluster around a few screens (or functions) in your application.
- You recognize a similar pattern in source code that keeps popping up.
When you see patterns like this, you can certainly keep on fixing the bugs one at a time, but it's pretty hard to make progress this way. Instead, consider a larger bug fix, or even an actual feature (there's really no difference, IMO) that cuts across individual bugs and fixes the foundational problem that's spawning them.
- Maybe you need to redesign a screen. If users are having a hard time figuring out part of your application, you're not going to be able to fix your users. Bite the bullet and figure out what you need to change in your application so that it makes sense.
- Refactor ugly code. This should be a no-brainer. Spaghetti code can hide a multitude of sins, and the bugs are just going to keep coming until you deal with the problem.
- Address architectural issues. Sometimes, your problems run really deep, and big changes are needed to fix them. This can be a tough sell, but if you can show a pattern of costly bug fixes over time, all of which share an architectural root cause, you've got the ammunition to push for a fix that will make them go away.
If you eliminate the sources of these clustered bugs, you not only get rid of the current bugs, you wipe out a whole swarm of future bugs before they've had a chance to show their ugly little faces. Don't believe for a second that you can do this one bug at a time.
Related articles by Zemanta
- Dealing with bugs in Linux (ghacks.net)
- Software Bugs A Software Architect Point Of View (slideshare.net)
- Over Half of Software Fails First Security Tests (tech.slashdot.org)
Refreshing to see this to bring the cause and effect back into focus, when there are so many other things to look after. Software will always be buggy for the simple reason that no one can list, much less realistically test for, all the permutations and combinations that are embodied in code. Bug tracking applications are helpful to the extent that they are actually used. The hardest to squash are those not of our own making, such as an update on a another vendor's dependency.
Chuck Brooks
Futureware SCG