Prototype pitfalls

In software, a prototype seems to work like the finished product. In reality it's usually a pretty face (GUI) with minimal functionality.


If you actually try use the prototype you will discover that it only works for a limited set of actions, if at all.


My first introduction to a prototype was in the mid-1990's. My good friend Jack Kustanowitz arrived at Kivun (of Dagesh fame) as a summer intern. 


Netscape had just released the first Web Browser - and all you could do was browse. Maybe it also had a back button that went to the previous page.


Using Visual Basic, Jack created a prototype of WebTamer; everything your browser needed. Functionality like "History", "Off line browsing" and "Bookmarks".


And it seemed to work! Making a product out of it should be trivial, Project Management was assured. (These were the same non-techie Project Managers from yesterday.)


Suffice it to say that the road from Prototype to Release was long and painful, since the prototype was mainly a GUI; a pretty face, and Jack-the-wiz-kid was back in college.


Prototypes of the graphical interface are easy to create, very impressive and very misleading to Project Management - and Management in general. It's hard to see why a product which looks ready-to-use will need months of development before it can be shipped.


Sometimes a prototype is used as a technical proof-of-concept. Being unsure of the capabilities and limits of certain technologies, a team will implement some functionality with technology they have never used before. Usually some new emerging technology. 


They can then measure:

• How long did it take? Does this seems like a faster way to implement features?
• How stable is it? If we stress the application does it crash or slow down?
• How fast is it? If they implemented existing functionality, they can benchmark it to see if it's faster or slower than the existing implementation.

In this type of prototype, the important functionality will be there, but the GUI may be missing. 

Can the prototype code be used in the end product? Sometimes; often it cannot as the prototype will have been done without a technical design;  that crucial design stage that ensures that multiple programmers can safely and efficiently work on the same code.

What a Project Manager needs to realize is that prototypes - both types -  are not an indication of a finished product, no matter how good the demo looks or functions.

The connection between a prototype and the end product is often similar to the connection between an ad and the actual product, or the trailer of a movie and the actual movie. You've been shown the highlights; the devil is in the details.

Lessons learned:

Having a "working prototype" will not in any way shrink the schedule. "It's almost ready" is not true.

A prototype does not absolve the Project Manager from creating a fully blow functional specification document. Assume all the functionality is missing. What you see in not what you will get.