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!
Why Are You Prototyping?
Beware of the prototyping trap. If you ask two programmers on the same Visual Basic team what a prototype is, you're likely to get two different answers. Often the team is unclear whether or not the prototype is a throwaway. Ensure that the term "prototype" is well defined and that everyone (including the users) is familiar with this definition. You might even choose to define different types of prototypes. The big trap is to leave the "prototype" ill-defined. We have seen this lead to much grief on many Visual Basic projects. Prototyping in general has been given a bad name because of frequent misuse.
Delivering quickly is often the justification for a prototyping approach to development. But without control, the "what" that is delivered usually fails to meet the business needs for robustness and maintainability.
To be successful, prototyping must have specific goals, such as these:
Goals to demonstrate feasibility
Analysis goals to discover or confirm requirements
Design goals to prove the technology or an approach to implementation
Implementation goals to evolve a working system with user involvement within a predefined technical architecture
Uncontrolled prototyping, without goals and a development strategy to produce an application architecture, is doomed. It is hacking with respectability.
Prototyping can be used at various stages during development. The key principle that will ensure that prototyping is used correctly is to precisely define the objectives of the prototype and then ensure that appropriate disciplines are used to deliver these objectives. Rules such as "Prototypes must be thrown away" are unnecessarily restrictive.
