I spent part of yesterday interviewing for new positions. That is, after all, the life of a contractor – we finish up one project then go out to find the next. One of the interview topics got me thinking, always a bad sign. The topic was prototyping, and the question was “how far do you go”?

Now, prototypes sound great when project managers and architects talk about them. Project managers see them as a way to clarify the future requirements in terms of time, functions, and resources. System architects revel in the concept of creating “tangible” mock-ups for unclear functional requirements. Developers like to get right into the code and our customers like to see a “product” up front. It looks like the kind of “win/win” situation so beloved but theorists.

The principle is indeed sound. But like so many principles, the translation from principle to method and into technique muddies the waters. Some of the questions you have to answer include:

1) Who do you involve in the build?
A prototype thrown together by two leads will look a lot more like the final product than something you farm out to a junior developer. Unfortunately two leads, stripped of the constraints imposed by ordinary process, can probably pull together a prototype which actually works rather than just being a mock-up. Working software prototypes have a nasty tendency to escape into the wild.


2) What functions you include in the initial prototype?
If the purpose of the prototype is to concretely display solutions to particular business problems, then it seems reasonable to say that the functions we need to include would involve resolving those problems. Like so much of project management, though, saying is one thing and doing another. A prototype with a mock-up of the UI but no association with the business logic does little good; a fully detailed prototype with functional logic and the majority of the requirements in place results might as well be a mid-project iteration.


3) When do you allow customers to touch the prototype?
Early and often may be the knee-jerk reaction, but experience argues that overexposure to prototypes can set some very unrealistic expectations in both developers and customers. Customers see the “working” prototype and wonder what’s taking so long; developers work long hours to get the prototype working then end up throwing out almost all of the code to start wrestling with the real production issues.

4) Where do you allow the prototype to exist?
A prototype usually comes into being in a vacuum, isolated from other systems and unfettered from the organization’s development process. This allows it to come into being in an almost Platonic form, sprung whole-cloth from the developers minds. If it escapes from development, though, it will come into contact with real activities and the unfortunate realities of data structures in the corporate world. At the same time, customers want the prototype to interface to some extent with “real” data so they can understand how the finished product might behave.

5) Why will the prototype help you in this specific situation?
It’s time to be bluntly honest for a moment. Prototypes do not always help the situation. In fact, sometimes handing the customers a shiny toy, especially one with a few bells and whistles, exacerbates an already bad situation. In these cases it makes more sense to keep the prototype isolated with your own team, using it as a framework for your development effort rather than a customer relations tool.

Obviously we could ask even more questions. The point is that something as seemingly obvious as the principle of prototyping becomes convoluted as we move though the interactions of people, process, and technology making up even a simple project.