Looping the Loop

One of the most effective ways of restraining soaring bug rates is to attack the problem at its source—the programmer. Programmers have always known about the huge gap between the quality of code produced by the best and by the worst programmers. Industry surveys have verified this folklore by showing that the least effective developers in an organization produce more than twenty times the number of bugs as the most effective developers produce. It follows that an organization would benefit if its better programmers produced the majority of new code. With that in mind, some corporations have introduced the simple but revolutionary idea that programmers have to fix their own bugs—and have to fix them as soon as they are found.

This sets up what engineers call a negative feedback loop, otherwise known as evolution in action. The more bugs a programmer produces, the more time he or she is required to spend on fixing those bugs. At least four benefits rapidly become apparent:

1. The more bugs a programmer produces, the less chance he or she has of working on new code and therefore of introducing new bugs. Instead, the better programmers (judged by bug rate) get to write all the new code, which is therefore likely to have less bugs.
   
   
2. Programmers soon learn that writing buggy code is counterproductive. They aren’t able to escape from the bugs they’ve introduced, so they begin to understand that writing solid code on the first pass is more effective and less wasteful of time than having to go back to old code, often several times in succession.
   
   
3. Bug-prone developers start to gain some insights into what it’s like to maintain their own code. This awareness can have a salutary effect on their design and coding habits. Seeing just how difficult it is to test that extremely clever but error-prone algorithm teaches them to sympathize more with the maintenance programmers.
   
   
4. The software being written has very few known bugs at any time because the bugs are being fixed as soon as they’re found. Runaway bug lists are stomped before they can gather any momentum. And the software is always at a point where it can be shipped almost immediately. It might not have all the features originally requested or envisioned, but those features that do exist will contain only a small number of known bugs. This ability to ship at any point in the life of a project can be very useful in today’s fast-changing business world.

Some people might consider this type of feedback loop as a sort of punishment. If it does qualify as such, it’s an extremely neutral punishment. What tends to happen is that the developers start to see it as a learning process. With management setting and then enforcing quality standards with this particular negative feedback loop, developers learn that producing bug-free code is very important. And like most highly motivated personalities, they soon adapt their working habits to whatever standard is set. No real crime and punishment occurs here; the process is entirely objective. If you create a bug, you have to fix it, and you have to fix it immediately. This process should become laborious enough to teach developers how to prevent that type of bug in the future or how to detect that type of bug once it has been introduced.

Some Final Thoughts Set a zero-defect standard and introduce processes that emphasize the importance of that standard. If management is seen to concentrate on the issue of preventing bugs, developers will respond with better practices and less defects.