Ways of Ensuring Quality | Advanced Microsoft Visual Basic (Mps)

There are very few people who don't become more interesting when they stop talking.
Mary Lowry

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 for the review process (both for those being reviewed and the reviewer) 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.

Demand More Rigor, Not Less

It's a funny thing about life; if you refuse to accept anything but the best, you very often get it.
Somerset Maugham

A desire for quality and technical purity encourages a rigorous approach to development. Formal methods such as VDM (Vienna Development Method), Z, and B are rarely used in commercial development. But methods that promote rigor (such as SSADM) continue to have a high level of use. Do they work? They can work well in the hands of skilled project managers who know what to use and what to leave out for a specific project. In unskilled hands, the level of rigor applied tends to be higher than necessary, project costs soar, and schedules slip.

In some organizations, the consequence of the failure of rigor is that business managers decide to do their own development. In others, hacking takes over. Visual Basic 3 was one of the main tools of the hackers. To continue to use this approach with Visual Basic 6 is at best a waste and at worst a disaster. The development process for a project should be decided by the project manager with the guidance of the analysts and designers. Prescribing a method from outside the project does not work. A Pathfinder approach provides a mechanism for understanding major projects before you commit large numbers of staff to them.

Teach the Fundamentals

As far as the code is concerned, there appear to have been several passes through it. The later passes introduced several bugs. The person or people involved do not appear to understand the Visual Basic event model.
Code review

Tools and methods are only as good as the people who use them. They are no substitute for training. Staff must know why as well as how. The why comes first.

The basics of computing—how chips work, how memory is used, what operating systems and algorithms do—are all essentials for IT professionals. The lack of this fundamental knowledge means that developers effectively cannot use powerful tools such as Visual Basic 6. They need to understand exactly what the tool is doing and how it works. This knowledge is even more important as the tools become more powerful because they hide so much. To use distributed objects effectively, for example, one has to understand how the technical mechanisms that create the objects work, not just how to make them work. How is a local call turned into a remote call? What is the effect on the network? How does it perform with high transaction rates? What is the impact of other network traffic?

The fundamentals of software engineering must be taught to staff. The principles of data management, security, configuration management, project control, and so on apply to all development approaches. The divisions and disciplines of separate development, test, and production environments are critical to successful implementation. The ability to produce code quickly in Visual Basic 6 doesn't relieve developers and managers of the duty to produce the right code and to use the technical infrastructure correctly and efficiently.

Commit to Staff

Good people are good because they've come to wisdom through failure.
William Saroyan

Good software developers are infinitely better than average ones. The only people worth having on the team are those who are very good and those who are very eager to learn. You can tell people who are good at their jobs a mile off. A team of people who are proud of their work is a thousand times better than a team of average people. High-quality teams lead to real team spirit. At TMS, our hiring process includes a strictly monitored 2½-hour written Visual Basic examination. We never rely on just résumés, references, and interviews. We firmly believe in small, highly skilled teams.

In Visual Basic teams, there is a danger of everyone "doing it all." The Visual Basic 6 box is deceptively small, but there's an awful lot in there (like Dr. Who's TARDIS). Most Visual Basic programmers become jacks-of-all-trades but, of course, masters of none. We therefore believe in specialists across the teams.

Because of Visual Basic's high productivity, it's possible to reach a productivity saturation point long before achieving competency. "Productive incompetent" programmers are the result. Visual Basic programmers need much better education and training. Most employers seem to think that sticking their mainframe programmers in a five-day introductory course is enough. Wrong, wrong, wrong. So many times, we've seen people with inadequate training—for example, with no understanding of the workings of the Microsoft Windows operating system—building mission-critical Visual Basic applications. They assume that they are working in a protected environment with "limitless" resources, just as in the mainframe world. Visual Basic programmers should have a thorough understanding of Windows as well as Visual Basic functionality and syntax. They should also spend at least six months working alongside an experienced Windows/Visual Basic mentor before being let anywhere near an important development project.

Go for the best

One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man.

Elbert Hubbard

Visual Basic 6 distributed development requires that developers have a broad range of technical skills and understanding that covers front-end, middleware, and back-end technologies. Products such as Visual Basic are getting bigger and more sophisticated. Rapid development means shorter analysis, design, and coding stages. Effective staff utilization dictates that the same staff are used across all stages. The implication is that higher-caliber, better-trained, and better-paid staff are needed. Visual Basic 6 distributed development requires stronger analysis because of the more competitive business environment. Design, testing, deployment, and support skills need to be stronger because of the more complex technical environment.

Project managers must be technically competent and have strong business and interpersonal skills. Their management of the users and their own teams has grown more difficult. With the breadth of skills required and the pace of technical change, it is unlikely that team members will have a full set of the required skills. Working together to solve problems, to experiment, to learn, and to cover skill gaps is essential to Visual Basic 6 distributed development. Project managers must build learning time into the schedules. If overall development costs are not to rise, greater productivity must be achieved. The quality of project management is the key issue in building teams and commitment. A project manager must be a good team builder and team leader.

Some of us have had the rare experience of working in highly cohesive, effective, productive, supportive, and fun teams. From a management perspective, productivity and effectiveness are the only important factors. But these two factors don't come without the others; in fact, they are a result of having developed a supportive, cohesive, and fun environment. Unfortunately, such teams often break down after a short period. Few managers have the skills or support to build and maintain such teams. The best organizations have human resources departments that provide management training and facilitate team development. Some managers treat team building with cynicism. They are fools who are making their own jobs much harder.

Many organizations build teams successfully and then destroy them. Staff must be motivated by training, advancement, recognition, involvement, and money. They must not be demotivated by lack of respect, unreasonable pressure, long hours, or lack of consultation on matters that affect them.

In the case study, we recommended a resource pool—but beware. You can have a resource pool of laptop computers, cars, overhead projectors, or any inanimate objects. You can manipulate them with little thought. People deserve better. They are not things to be moved about on a whim. The resource-pool concept needs to be handled carefully. A good team is more important, more productive, and more effective than the best methods, the best tools, or the best organizational structure. The priority must be on building and maintaining a good team. This investment provides the greatest payoff.

If you commit to staff, they are more likely to commit to you. And successful Visual Basic 6 distributed development requires high levels of commitment from staff. They need to spend their own time researching their tools, and they need to be encouraged to do so. Their commitment must be reciprocated in terms of salary, holidays, working hours, personal development, training, respect, and fun. Good staff can command high contract rates and are mobile. Reward them or lose them. The value of providing appropriate rewards outweighs the costs of poor productivity and poor quality. Refer to Chapter 17 for more thorough discussion on staff hiring and retention.

Project teams using Visual Basic for distributed development projects are often weak in their server-side skills. This is particularly serious where this extends to the project management and designers. Project managers might not schedule the time or resources to carry out physical design or be aware of the risks inherent in their project. It is essential for successful completion of any project that a realistic view of the skills required and those possessed be taken.

There are no experts

The true leader is always led.
Carl Jung

The rate of change in hardware, system software, and development tools means that there are no experts. Visual Basic 3, 4, or 5 gurus are not Visual Basic 6 gurus. With lack of expertise and rapidly changing environments, it's difficult to build a stable and effective technical infrastructure. It's even harder to get good advice on how to use that infrastructure.

A development project is unlikely to have teams with all the skills required in sufficient depth to deliver the project. A realistic assessment of the skills required and those possessed should take place. Any deficiency should be filled for the project and a longer-term solution developed. A good approach is to employ external consultants who have skills transfer as part of their experience. It makes no sense to incur extra expense by continually running to outside resources for core skills.

Three roles are essential in designing Visual Basic 6 distributed systems:

The system architect creates the overall conceptual design.
The system designer carries out the detailed specification of the executable code and the implementation.
The DBA is the database technical expert.

Other experts, such as language or network gurus, might be required to solve particular problems. In addition to these roles, the complexity of the systems demands external review.

You can learn a lot from those who have more experience, so form a partnership to learn more. The problems are complex, and so are the solutions. You might never know whether you have the best solution because the technology is moving on before it is proved. We repeat, there are no experts!