Featured White Papers

Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Bug patrol

Automate your software improvement process

By Joe Walker, JavaWorld.com, 11/21/03

Print
Feedback

Plenty of freely available tools can easily give you reports about what is wrong with your code, thus helping you to improve its quality. And because "wrong" is often subjective, most of the tools can be configured to fit in with your local coding style.

But first it is worth questioning your commitment to reducing bugs. This might sound like a simple question—surely software quality must be a priority for everyone. However, it often seems reasonable to spend minimal time altering code. Any software with a short shelf life should be edited as little as possible, and it is pointless writing a single line of documentation no one will ever read. I wonder how many pieces of documentation have cost more in terms of writing and reviewing than they have saved by somebody reading them? Our aim, therefore, should be to distinguish between jobs worth doing to improve the quality of our work and jobs that are a waste of resources.

How far do you want to go to make your code better?

Several bug categories exist. The tools I look at differ in the types of bug they target. I've identified four different bug categories, which vary in severity from the common or garden bug that annoys users to organizational bugs that prevent code reuse:

Current bugs: Current bugs prevent the software from working properly now. They can annoy users and are (or should be) highlighted by your software testing. Current bugs are distinct from latent bugs.
Latent bugs: These bugs do not cause problems today. However, they are lurking just waiting to reveal themselves later. The Ariane 5 rocket failure was caused by a float->int conversion error that lay dormant when previous rockets were slower; but the faster Ariane 5 triggered the problem. The Millennium bug is another example of a latent bug that came to light when circumstances changed. Latent bugs are much harder to test using conventional testing techniques, and finding them requires someone with foresight to ask, "What could change that might bring the bugs out from the woodwork?"
Accident-waiting-to-happen bugs: Code can be simple and safe, or it can be a dangerous mess waiting to trip up the poor programmers who didn't think long enough about their edits' consequences. Generally, the older the code is, the more likely it is to have sharp, rusty edges; and some industry evidence shows that code not refactored over time ends up requiring a rewrite after an average of seven years.
Poorly organized bugs: Poorly organized code is not easily reused and often contains dependencies on more code than necessary. It is consequently more likely to be affected by bugs in other bits of code. Coding standards address this type of problem, but coding standards are not the whole story. They do not stop problems like cyclic dependencies, for example, which kill your chances of maintaining reusable code.

These issues are roughly organized in order of severity. Current bugs are generally more problematic than latent bugs, which are in turn more worrisome than accident-waiting-to-happen or organizational bugs.