Visual Programmer
By Peg Byers
Part II: A Typical Situation
Visual programmers design and build the "front-end" of the application-what users see and use daily. The data entered and retrieved by users are stored in a database at the "back-end" of the application. The database may reside at the user workstation. Most often it resides on a network server, or in large organizations the database may be distributed-parts of it exist in different locations. Distributed systems can reduce time and costs of retrieval for users across broad distances. When the "back-end" storage is within a "foreign" (to the front-end language) database management system, complex connections between the front and back ends are programmed for accurate, timely retrieval and display. Answers to questions (queries) and reports of data must appear quickly and transparently (without knowledge of complexity involved) to front-end users.
Improved communication between programmers and their public due to the visual tools available can produce unfortunate situations, however. Analysts and programmers involved in the initial JAD/RAD session meetings with users must avoid making the development process look "too easy." It is important to ascertain exactly what is "essential" to the planned upgrade of a system or introduction of a new one. Users can understandably be excited at the prospect of having input to a system design that makes work easier, faster, or more fun; programmers can to be eager to please by promising too much, too soon with too little research. This kind of dilemma results when crucial members of the "customer team" (users of the old/new system) forget to include all facets of a job.
Alternatively, this problem occurs when essential members of this team are absent from JAD planning sessions.
The result of oversights may be a great-looking, seemingly appropriate application with impressive "widgets" (extra, superfluous tools) that does not do the job.
Hours of programming time (measured in dollars) are wasted in the attempt to disassemble and rebuild what may be an inappropriately designed application. In worst cases, project schedules are hopelessly delayed.
This can result in the failure of the project despite the hard work of everyone involved. Recovery from this disaster means analysis must be redone and prototypes redesigned now with input from all key people. After the repeat of these steps, a truly robust application-programming job can be completed. It is imperative that the lead programmer develops an accurate list of programmable tasks for a reasonable period. Users excited by the rapidity of development and the "apparent" ease of visual programmers to accomplish it must not be allowed to steer the project off course. Enhancements to the application (i.e., a "wish list") can be added later, once basic functions are operational. Visual programming adds to the increased productivity of technology-using companies. Its use aids communication between programmers and users. Key to its successful use is to "wisely" program visually and technically keeping everyone's "bottom line" firmly in mind.