Visual Basic —

Proof of Concept

As mentioned earlier, a key objective of the Pathfinder project is to prove to the business managers and to the IT teams that a business function can be delivered using the application architecture. Using the Pathfinder substantially reduces the perceived risk.

The proof of concept must include thorough testing of the application architecture. Such testing will cover, for example, stress testing the architecture. The architecture should be proven to be a viable basis on which to develop the entire application. Proof of concept includes delivery of the business function into a simulation of a live environment by those who would normally deliver the application. It should be delivered to the user for testing. Difficulties in managing rapid development in the IT department and in the business will be highlighted. Prove that you can deliver. Prove it to the business management, to the technicians, and to the skeptics!

Focusing on Design

When challenged, most Visual Basic developers would claim they design their applications. Unfortunately, we see little evidence of this. Technical specifications are becoming historical curiosities. It seems that most Visual Basic programmers cannot resist the temptation to start coding on Day 1 and then code, code, and code some more. What's wrong with using pencil and paper and applying a little thought up front to get a handle on a problem? As a contrasting example, tackling a large C++-based development is not easy at the best of times, and developers quickly learn that unless they invest some time in designing carefully, they will waste a lot of time and their development will almost certainly fail. How does this attitude compare with that of Visual Basic developers? We feel that Visual Basic is often abused. It's so easy to build an application that, rather than choose to design, developers build instead; that is, they take the "try it and see" approach to software development. In the Visual Basic 6 enterprise environment, this kind of approach spells disaster.

We recommend that not only must you create a design, you must make sure it fits in with an overall corporate architecture. The application design should be objectized, by building common objects and designing them for reuse. Error handling and debugging aids must be designed in from the start. When it comes to external components and objects, be careful not to include them in your design without properly assessing their quality and their potential impact on your application and on Windows. For example, at TMS, we run all candidate ActiveX controls under the Windows debugging kernel-it's often very revealing! Measure the effect on Windows resources of using a particular control, especially if your design means the control has to be multiply instantiated. More broadly, we recommend that external components and objects be assessed, procured, and controlled centrally-and with much care and thought.