Ways of Ensuring Quality

We started this chapter wondering about a Visual Basic quality crisis. As you’ve seen, many good practices seem to have been ignored. People who should have known better have gotten caught up in the productivity trap made so obvious by this special development tool. So how can you avoid the same trap? The old adage about an ounce of prevention being better than a pound of cure applies to Visual Basic systems development—there’s no better way of eradicating problems in a system than by not putting them into the code in the first place.

The best way to improve the quality of Visual Basic team developments is to introduce a formal review process. Reviews are also known as walkthroughs or inspections—nothing new, but rarely found in the Visual Basic world. We believe that defining standards is not enough: the standards also need to be policed, preferably by an independent QA team. Some excellent tools on the market automate this procedure.

The objectives of a review process must include these:

To ensure standards are adhered to
To improve the quality of software
To improve communication between developers
To improve code reuse

From experience, we’ve found that a review process is worthwhile only if it has total management backing; that is, implementation should be blocked until all reviews have passed in all circumstances, regardless of the business pressures to go ahead. Essential documents are a style guide (or user interface guide) and a set of standards, both of which should be second nature to all developers.

At TMS, we use a three-stage review process:

Requirements. This review gives the designer and developer an opportunity to ensure that the quality of the requirements specification document produced by the analyst is high enough and that it accurately and unambiguously describes the system.
Design. This review is further segmented into two reviews:

A first design review is carried out about 20 percent of the way through the design phase. This review is informal and normally involves the designer explaining the outline of the design on a whiteboard. This review verifies that the proposed design approach is sound. (It’s better to catch any design flaws early on, rather than waiting until a detailed design specification has been produced.) At this point, the team can agree on which reviews should follow; a modified review process can be appropriate depending on the project circumstances.
A second design review is carried out at the end of the design phase. This review is much more formal than the initial design review and involves careful scrutiny of the design and the design documents produced.

Code. This review is also further segmented into two reviews:

A first review is carried out 20 percent of the way through the coding phase. This review verifies that the proposed coding approach is sound and that standards are being followed.
A second review is carried out at the end of the coding phase. This review is more formal than the initial code review.

While it probably seems that this review process will cause a lot of extra effort, we have found that it actually saves a tremendous amount of time and cost in the long run.

There are, of course, many more ways to improve quality. For example, testing properly, maintaining metrics so that Visual Basic projects can be measured, and doing postimplementation reviews are just a few additional ways of monitoring quality.