Field prototyping for software - a practical approach to implementation
The basic problem with many computer projects is that they suffer from the effects of rigid top-down analysis. In this, the application is analysed, a comprehensive specification (i.e. blueprint) is written and programming proceeds, without deviation (in principle), from the specification. This is, to extend one of Prof. Hoare's analogies, rather like constructing a building directly from the architect's conception. The failure of analysis lies mostly in failure of communication between the analyst and the intended users. Typically, the analyst is a computer specialist and has no particular background in the intended application. It is unlikely, unless the subject is very simple, that the analyst (without background) will have a thorough, detailed grasp of the subject until long after the specification, if ever. How then, you may ask, does an analysis ever finish and how do programs ever get written? In my experience, the analyst simply listens to thetneeds of the users and directly translates these into a computer solution, often with little understanding of what he is doing. The translation of the desires of the users is indeed the job of the analyst, but unfortunately the users generally overor underestimate grossly the capabilities of the computer, or worse still, have no idea at all. In short, it is often a case of the blind leading the blind. The end product often looks like it. To put a fine point on it, it is safe to assume that the user will not know exactly what he wants in a program until he uses the program for some time. The result, as most commercial programmers will avow, is often a mess. The finished product may well have glaring omissions or completely misinterpret the application. At this point, frantic patches are made to the software until a usable product is tacked together. Frequently, however, the program is never adequate and the end users suffer badly. No matter how bad the product, it is almost never scrapped this would be considered the most grievous of failures. Programming itself is subject to several problems, even given a 'correct' analysis. The first of these is the testing of software mechanisms, many of which will fail, despite rigorous testing, once subjected to operation in the field. The second exists in the nature of programming, in as much as it is simple (and desirable) to create programs which transcend the ability of the creator to understand them. This makes it diff icult for the programmer to ensure that the overall operation of even fairly small programs will be correct, despite careful testing of manageable portions. I would sum up the defects of traditional program methodology as: