Pitfall: confusing prototypes with finished products

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

CATEGORIES: conceptual, managerial

Make no mistake: modern software development techniques and methodologies, combined with powerful user-interface classes and software development tools, can greatly speed application development. However, they also allow application prototypes to be put together and demonstrated very quickly. This is great for examining and testing various user interfaces, or for conveying the essential nature of the application being developed.

There is a drawback to this speed of prototyping. People not involved in development — notably, upper management, investors, and customers — consciously or unconsciously see the application as being closer to completion than it is. They find it hard to understand why the rest of development should take so long, not realizing that what they’re seeing may not have any code that is actually used in the final product.

Symptoms

A good clue for starters is someone not involved in development saying, “I don’t see why it’s taking so long; after all, you demonstrated the product [or a particular feature] to me several months ago.” Less-direct indications include issues of effort or competence or both being raised about the development team. For a more subtle, management-oriented variation on this, see “Mistaking feature prototyping with feature completion” (to be posted).

Consequences

Suspicion from nondevelopers that the development team isn’t working as hard as it could or is somehow incompetent. Loss of trust and credibility.

Detection

If you have reason to suspect that this is happening (due to symptoms or gut feelings), start asking for explicit feedback from the nondevelopers you’re concerned about. Here’s a good question: “Based on what you’ve seen so far, when do you think we’ll be ready to ship?”

Extraction

You absolutely must reset expectations and get the nondevelopers in sync with reality. The question mentioned above in Detection is a good place to start. Follow up by asking questions about how long the person thinks each of the yet-incomplete features or aspects should take to finish. Be sure to raise every single feature or aspect you can think of as well as noting completion dependencies. And don’t forget to point out the time it will take to debug, test, and verify all these features.

You need to ask them how long they think it will take because nondevelopers often have unconscious assumptions and expectations, which when dragged out into sunlight and examined, quickly shrivel and fade away. Left unexamined, however, they become a constant and unstoppable source of frustration, causing those people to be dissatisfied with whatever progress you’re making.

Prevention

The best solution: Don’t show prototypes to those not involved in development except possibly to potential customers doing testing and evaluation. Politically and financially, that restriction is not always feasible. If you must show prototypes, go to great lengths to set proper expectations ahead of time and do your best during the demonstration to show all the functionality that isn’t in place.

Be sure to point out all the work that remains to be done. Show every area that is incomplete or nonfunctional. Be conservative (that is, pessimistic) about the amount of time required to fully implement and test each feature. In short, make the prototype sound even more worthless than it is; you are always better off underpromising and overdelivering than the other way around.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.