Any application should be fully specified to begin with. The business rules should then be formally translated into a format specific to a computer based implementation. This naturally leads to data designs and specifications for the application programs needed to implement the application.
For as long as we can remember the search for software tools to automate this process has been a dream in the IT industry. There has of course been some progress but the ideal integrated case tools remain elusive. To be fair to the developers of such tools, there is a resistance from the application developers to push the concept., simply because the development of a significant application involves a lot of people and mo one has the overall authority to dictate methodologies. As a result there are too few users of the limited number of tools available and thus the tools are expensive. All too often the budget needed to buy advanced development tools seems too big and it is difficult to balance their cost against more programmers.
One of the most common techniques employed to improve application design is prototyping. Unfortunately this creates as many problems as it solves, many of them serious ones. There is a big difference between a maintainable business application and a prototype which unfortunately is not obvious to the end-user. Even worse it is not obvious to the enthusiastic new programmer, who lacks the experience to appreciate the fact that fixing a problem consumes more resource than doing it right in the first place.
The fact that we seem unable to accept is that tools for developing maintainable code and tools for rapid prototyping are fundamentally different. Prototyping tools and similar ones for "proof of concept" exercises need to be easy to use, interactive and heavily biased towards the image that the end-user will see. But the final application will have a long life and will need ongoing maintenance by a team of people, probably by different people over the years. The final application must perform well and must scale up to accommodate a large number of users, whereas two users is probably enough for a prototype. To develop an application which can scale up often needs a different architecture to a prototype. The problems exposed by client/server applications are all too common today. A thin client application, with all the application logic and the GUI presentation interface in the one PC is relatively easy to develop as a prototype using Visual Basic, Delphi or similar tools. The availability of components to help build the user interface over exposes the value of this concept. It looks extremely good to the user and to the inventive but inexperienced developer. But such an architecture means that all multi-user aspects such as record locking are extremely difficult to resolve. Further there will be a lot of network traffic since each and every PC workstation must have a copy of the whole application. When the same application is properly designed a lot of the effort goes into performance tuning under load, one aspect of which means reducing the network overhead and another involves sharing of common code on the server. Further attention must be paid to recovery and fault handling. Error checking at the point of data entry is essential in a production application but is not needed in a prototype. In summary a final production design involves issues of security, scalability, network performance, recovery and others which are simply not needed in a prototype.
If we ever get to a situation where automatic CASE tools are common, then the problem will go away, since such tools could generate a simple version for prototyping and then generate a full version when the design is accepted. But that is a long way off. Thus the current solution should be to use different tools for prototyping than for development, which apparently is something not accepted in the industry as a whole. It means building a prototype to get approval from the business designers and then using that as a specification from which to build the final product.. This may seem straight forward, but it isn’t. The problem still remains that no programmer or designer can be skilled with all tools and with all aspects of an application. The predominant techniques are thick client biased, which means that the developer must be expert at GUI interfacing, business logic, database design and networking. The tools available have improved of late, but they still don’t have the "team" approach common in established DP shops.
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.
