Like any high-level programming language, Visual Basic lets the programmer write really awful programs, and with Visual Basic, you can screw up more easily and faster than ever! As with programs in any language, a bad program in Visual Basic can be very hard to maintain. It can be hard to adapt to meet changing business requirements. But with Visual Basic programs, there is a greater danger than with other languages that developers will focus too much on a pretty front end without designing a solid structure on which to hang it. Important business logic can be attached to GUI widgets rather than placed in reusable objects, making it hard to share and reuse code. And of course, Visual Basic is the perfect tool for maverick code warriors to pump out reams and reams of undocumented and incomprehensible programs. All these factors can lead to severe maintenance and quality problems.
Managers often forget that the Visual Basic coding phase typically takes about 20 to 30 percent of the overall development life cycle. Their expectations of the massive productivity gains to be had from using Visual Basic are totally unrealistic. They have been suckered by the rapid application development (RAD) hype. We feel sorry for Visual Basic-unrealistic plans for it are often drawn up and agreed to, and later the true picture becomes apparent. Then we often hear such laments as, "We can't cut functionality-the business won't tolerate it," or "We can't slip the deadline-it's set in stone," or "We can't throw any more bodies at it without blowing the budget!" When the going gets tough, one or more of the following four things tends to happen:
- Functionality is cut.
- Deadlines are slipped.
- Bodies are added.
- Quality is reduced.
So what gives? Invariably, it's the quality that suffers the most. And Visual Basic itself gets the blame.
The goals of the organization often conflict with the goals of the Visual Basic team. The organization realizes that building reusable components increases its ability to build better solutions more quickly, whereas individual project teams are typically focused on solving specific problems under tight schedules. The Visual Basic team is pushed so hard that it's next to impossible to consider reuse, despite the fact that the team members would love to generalize their code and make it available to other teams. Unfortunately, they don't have the time to consider problems outside their project.
So is Visual Basic a poor tool for serious enterprise development? We don't think so-quite the contrary. Does Visual Basic 6 solve the problems of the past? It certainly helps. But it can't help solve many of the problems highlighted above because most of those problems relate to people-their attitudes toward Visual Basic software development and the processes they use.
How can Visual Basic software quality be maintained in an enterprise environment? Advanced programmers need the answer. In this chapter, we've listed the simple measures that we consider lead to the production of high-quality Visual Basic 6 applications. We don't aim to present detailed and reasoned arguments. Our views have been honed from years of experience-going all the way back to version 1-observing both good and bad practices in many large organizations developing Visual Basic systems: self-evident truths.