The Customer s Task in the Early Days of Software Development Methods

In the beginning, the clients role was to examine prototypes. That is, clients did not take part in requirements formulation. There turned out to be two kinds of prototypes . One demonstrated the interface to the users. This placated the IKIWISI ( I ll Know It When I See It ) users. The other tried out different things in the requirements to check feasibility.

The problem with the former type of prototype is that the closer a developer gets to a sensible interface, the more the client wants it. As tools like Visual Basic come to dominate the user interface market, the interfaces appear like real software. Clients who do not know the purpose of interface prototypes want to take the product with them, not realizing that there is little behind the curtain. This is why we often tell our developers to prototype the user interface using Post-It notes on a whiteboard. We have never seen clients leave a room with a whiteboard under their arms! It is obviously not necessary to code the interfaces, unless there is doubt that the physics prototypes can be done. Just do not show clients the coded version ”they ll often take it with them, expecting it to be a product.

The second type of prototype, the feasibility study, has its own possible problems. Some years ago, one author (Jim Tomayko) led the production of a museum exhibit. The exhibit was a kiosk that allowed patrons to try the counterintuitive task of orbital rendezvous. As with many museums, this one heavily depended on its patrons for support, one of which had donated an early model of the Apple, Inc., Macintosh . The curator was especially concerned about accuracy, so one question became whether the small computer could in reality do the mathematics of orbital rendezvous while displaying the Space Shuttle orbit and a hypothetical space station as a rendezvous target.

One subteam was dispatched to do the interface, while a single mathematically oriented (we thought) developer did a prototype of the orbital calculations. Both worked well, and both worked tightly within time ranges, so we proceeded with development. During a design review, it came out that the feasibility prototype we had used for the orbital calculations was flawed. The prototype had adjusted the gravitational constant (well, it was supposed to be constant) G until the equations worked. The equations, although altered for accuracy, still worked simultaneously with the interface, fortunately.

The use of prototypes in industry encountered significant resistance. This resistance peaked when some managers saw prototype code being thrown away. That struck the wrong chord with those spending money on something that they thought was concrete. The idea of having the specification and design explored and improved up front eventually became attractive.