Visual Basic —

Jumping Out of The Loop

One psychological factor responsible for producing bugs and preventing their detection is an inability to jump from one mind-set to another.In our push to examine subtle details, we often overlook the obvious. The results of a study performed a decade ago showed that that 50 percent of all errors plainly visible on a screen or report were still overlooked by the programmer. The kind of mistake shown in the preceding sentence ("that" repeated) seems fairly obvious in retrospect, but did you spot it the first time through?

One reason for this tendency to overlook the obvious is that the mind-set required to find gross errors is so different from the mind-set needed to locate subtle errors that it is hard to switch between the two. We've all been in the situation in which the cause of a bug eludes us for hours, but as soon as we explain the problem to another programmer, the cause of the error immediately becomes obvious. Often in this type of confessional programming, the other developer doesn't have to say a word, just nod wisely. The mental switch from an internal monologue to an external one is sometimes all that we need to force us into a different mind-set, and we can then reevaluate our assumptions about what is happening in the code. Like one of those infuriating Magic Eye pictures, the change of focus means that what was hidden before suddenly becomes clear.

Some final thoughts If you're stuck on a particularly nasty bug, try some lateral thinking. Use confessional programming-explain the problem to a colleague. Perhaps take a walk to get some fresh air. Work on something entirely different for a few minutes, returning later with a clearer mind for the problem. Or you can go so far as to picture yourself jumping out of that mental loop, reaching a different level of thought. All of these techniques can help you avoid endlessly traversing the same mental pathways.

Getting Our Hands Dirty

Steve Maguire stresses that many of the best techniques and tools developed for the eradication of bugs came from programmers asking the following two questions every time a bug is found:

  • How could I have automatically detected this bug?
  • How could I have prevented this bug?

In the following sections, we'll look at some of the bugs Visual Basic 6 programmers are likely to encounter, and I'll suggest, where appropriate, ways of answering both of the above questions. Applying this lesson of abstracting from the specific problem to the general solution can be especially effective when carried out in a corporate environment over a period of time. Given a suitable corporate culture, in which every developer has the opportunity to formulate general answers to specific problems, a cumulative beneficial effect can accrue. The more that reusable code is available to developers, the more it will be utilized. Likewise, the more information about the typical bugs encountered within an organization that is stored and made available in the form of a database, the more likely it is that the programmers with access to that information will search for the information and use it appropriately. In the ideal world, all this information would be contributed both in the form of reusable code and in a database of problems and solutions. Back in the real world, one or the other method may have to suffice.

Some final thoughts Document all system testing, user acceptance testing, and production bugs and their resolution. Make this information available to the developers and testers and their IS managers. Consider using an application's system testing and user acceptance bug levels to determine when that application is suitable for release to the next project phase.