Recently I made the point that there is a significant difference between a prototype and a production system. Because of this difference it is impossible to create software tools which are ideal for both the prototype and the final system; there must be some compromise.
There are two extreme stances that can be taken by developers. On one hand a development environment can be chosen that is deemed to be adequate for both requirements, while on the other hand two separate development systems can be used, one ideal for prototyping, the other for production. Both have there place and, of course, both have their problems.
The first concept, the common one for client/server applications, is simpler to use, but introduces solutions which have trouble with scalability, performance and maintainability. It is the naïve use of the GUI PC application development environments that lead to the mass of problems now being encountered with thick client designs. It was the ease of use, particularly for the GUI front-end, that encouraged designers to ignore the needs of production systems, i.e. network performance, recovery, etc. It is worth noting however that it is not the tools per se that are at fault, but the incorrect use of them. Such tools can be ideal for developing the client part of a thin client application, using other more appropriate tools for developing the server side code.
The second alternative seems the best, but it requires two teams of developers. Worse, it requires understanding and cooperation between the different developers, a prototyper focussing on the user’s needs, the production system developers concentrating on the technical side. Prototypers can do a lot as individuals but application developers need to work in teams.
One obvious fact that we must face is that there is no ideal solution at the present time. It all goes to emphasise the fact that we still need a practical implementation of the CASE Life Cycle model, when translation of a design can be made to a prototype, the approved design then being automatically generated as a production system. With this degree of automation there is no need to compromise at all and the best prototyping and development tools will be automatically employed. It would also allow various architectures to be exploited. This approach will be the best way to introduce the concept of reusable components. The same techniques are already the norm for hardware development; why are we so slow in adopting software components beyond controls for GUI interfacing?
If we step back and look at the current situation it becomes clear that the problem is more one of people than of technology. Any comprehensive business application involves a lot of people from users through to maintainers. This leads to vested interests. The old mainframe programmers were skilled at handling TP monitors and complex file structures. When GUI interfacing surfaced they knew nothing about it and most considered that they had enough to do already. Thus a new generation of programmers appeared who naturally became the experts at GUI interfacing but knew nothing about business transactions. Instead of working together two antagonistic schools developed; indeed it took IBM at least five years to release the appropriate software to implement a thin client model in which a GUI PC client could access host-base CICS transactions. What a disaster! As a result users either had to manage with character interfaces or have new PC network applications developed from scratch. The PC programmers knew no better and they tried to develop systems based on file sharing, mostly Novell Netware in those days. Such a blunder seems inconceivable today, but it simply shows up the stupidity of failing to work together, to take advantage of the best skills in a coordinated way. Unfortunately, ten years later, while not so bad, we are still making a lot of the same mistakes.
There is a big difference between the situation of an application package vendor and an in-house development team. There is absolutely no excuse for a package developer who doesn’t exploit the best available tools; they must use a mixture of design, prototyping and production tools. If an in-house development is a major one, then the same considerations apply, but most in-house development is focused on smaller applications and the economics of using a PC-based Rapid Application Development system is difficult to ignore, but when should one be replaced?
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.
