Some questions to consider when prototyping a system

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.


I think the word prototype may be somewhat misleading based on the questions you are asking. Per Encarta (similar definitions in other dictionaries): prototype (n) 1. original used as a model: the original form of something, which has the essential features and is the model for subsequent forms 2. full-size functional model: a first full-size functional model to be manufactured, e.g. of a car or a machine 3. standard example: a standard example of a particular kind, class, or group 4. (biology) primitive form: a primitive form believed to be the original type of a species or group, exhibiting the essential features of the later type Definition 4 is biology-specific, so doesn't really apply here. You aren't talking about standards and classes, so definition 3 isn't it either. That leaves definition 1 or 2. Definition 1 includes "has the essential functions", definition 2 has "functional model". When you mention a non-functional mock-up, that's not actually a prototype, per definition. That's what should be called a "model". (Yes, I know, I'm brining engineering concepts into this, but it is an engineering question.) So, is the question, how far should you take modeling, or is the question how far should you take prototyping? These are not the same question and have different considerations. A model (non-functional mock-up), should have the look of the final product, but doesn't need to have any functionality at all. Perhaps some buttons would have an animation to them (if what you're modeling is a form with buttons on it), but they wouldn't actually do anything. A prototype needs to have the essential functions working. In software, this is often where alpha testing of code is going on.


It seems you left one important little detail- Who pays for the prototype? How far into the project do you propose a serious prototype? With that in mind, I would think it's time to show some progress to the client, which would mute your idea of devoloping it in a total vacume. (which in most cases is a bad idea, you need input from the end users, the sooner the better.) Of course, having some possibly unused prototypes laying around could come in handy.

Tony Hopkinson
Tony Hopkinson

Whether it's your techs going daft, unmanaged development, or a salesmen getting a bit previous. When doing a prototype, you have to define why. Why are you prototyping, what is the objective, what is the minimum work that must be done in order to achieve the objective. Never ever, make a 'working' prototype. A working application is fine, a prototype, that allows you to investigate the issues of concern is fine. Make a working prototype and someone will sell it, then all the nasty compromises you put in becasue it was a prototype will come back and haunt the crap out of you. A prototype should give you a proven plan on how to design and implement a piece of software, if you are going to use the prototype code without at least a serious and exacting review, it isn't a prototype. It's version 1

Editor's Picks