Prototype - friend or foe?


Prototype ‚ friend or foe?

Many developers create prototypes (or demo applications) to show potential clients . It could be an application based on an application done for a previous client (or in some cases the exact application with client permission, of course) or just something they whipped up in their spare time to showcase their talents. In any case, these are more like demoware deployment we discussed in the ‚“ Demoware ‚½ section of this chapter. This section discusses providing prototypes for custom applications. A prototype to software developers is like the scale model of a building to an architect.

Because most clients don ‚ t really know what they want and their human nature is to see and touch, developers create a prototype based on the requirements a client provided after the first meeting or two. This can turn out to be a very positive step or very negative step depending on how well you communicate with your client about what they are really seeing. Without thoroughly discussing the fact that prototypes are only for show and tell, and all code will be thrown away, most clients assume the application is almost complete. After all, you did such a good job in two weeks. How much longer can it take to complete the entire application? This can lead to some very disastrous results. For instance, the client may become very upset when told it will actually take six months to complete. They did ask for a secure web application to run on all OS ‚ s Win95 or greater, Mac ‚ s OS 9 or greater, and all major browsers IE, Netscape, and Safari didn ‚ t they? This is like asking the architect after viewing the scale model ‚“So, when can we move in? ‚½ Well not exactly, but you get the point.

Sometimes developers can be their own worst enemy when it comes to prototypes. You just got a standing ovation for your demo from the client and they signed the contract. You are excited to get started. You sit down and continue coding from the prototype ‚ s code. But wait ‚ didn ‚ t you just ‚“throw ‚½ this code together for demo purposes? Most developers we know don ‚ t get paid or get much time to create prototypes that include all of the object oriented development best practices to establish a strong application foundation (unless of course a proven framework was used, but even then quite a bit is probably missing). This practice of coding from the prototype leads to problems down the road when enhancements or changes are required. It could lead to longer turn around times, because the time to refactor prototype code is much longer than refactoring best practices code. Rule of thumb: prototypes should be thrown away.

Using a latest and greatest technology not thoroughly proven is another disaster-waiting to-happen practice developers employ in prototypes. They get it working for the demo and the client falls in love with it only to find out a few weeks before installation it could take as much as 4 more weeks (or longer) to develop a work around in order for the application to work with one of the browsers included in the specification.

To avoid the above disasters you have a few choices:

  1. Don ‚ t show the client a prototype based on their specific requirements. Show the client a generic prototype that showcases your talents.

  2. Thoroughly communicate to the client just what a prototype is. Remind them it is only a shell and it will be thrown away. Maybe even have them sign a contract stating they understand this.

  3. Don ‚ t show them a prototype at all. Instead, show them screen renderings done using tools like MS Visio or MS Excel. Even hand drawings of what the screens will look like can be helpful.

Prototypes can be a positive software development process tool provided you and the client fully understand what a prototype is ‚ a demo. The client gets a good feel for what the screens look like and in some instances how they function. The client gets an opportunity to provide input sooner, rather than later, about what they like or don ‚ t like. A demo app helps set the expectations early on in the software development process. A prototype has the potential for reducing the number of change requests after development has begun.

So what do you think? Are prototypes friend or foe? Each custom application is different just as each client is different. Only you can decide if presenting the client with a prototype is a good idea or not.




Deploying Visual FoxPro Solutions
Deploying Visual FoxPro Solutions
ISBN: 1930919328
EAN: 2147483647
Year: 2004
Pages: 232

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net