The dirty secret of software prototypes
When we are not quite sure what we need to build, we build a prototype as a way of experimenting with different options and allow ourselves to take shortcuts and use hacks that in production code would be completely unacceptable. The intention always is to throw away the code at the end of the exercise, and use what was learned from it to write the functionality in a way that is supportable and maintainable.
The danger of doing this is that the prototype may look as if it fulfills the requirements, even though it doesn’t. A prototype is by its very nature too hardcoded and inflexible, is not scalable enough, doesn’t integrate properly with the rest of the system, doesn’t deal with errors or corner cases, and is not extensible which means that we can’t easily add the next important feature to the system without seriously violating something else that shouldn’t be violated.
In spite of this, it is actually ok to occasionally compromise and ship something that isn’t complete, but it mustn’t be a prototype. For example, the functionality in question may be very experimental and we have no idea whether anyone is even vaguely interested in it, so shipping it early allows us to test the market without investing too much in something that may have no value at all. If everyone jumps on it, the idea is that we then know that it’s worth the effort to invest more in it as soon as possible.
If this is the goal, the right approach is to produce a wireframe rather than a prototype. When writing a wireframe, we know what we want to achieve and we write it in a way that includes the right level of error checking, test code, etc, but don’t fill in many of the gaps that would be there if it was a fully completed feature - this can be done later, if the functionality turns out to be valuable enough.
The difference between prototyping, wireframing and developing a complete feature can be illustrated with an analogy to house building. The prototype is built from LEGO and all of the accessories are just pictures that look pretty from a distance, but is not likely to be particularly sturdy. In contrast, the wireframe has a solid foundation, walls, roof, and windows, but little in the way of finishing touches and accessories, which means that you can use the house even if it isn’t as comfortable as it could be. The full product of course is the completed article.
RSS
By Tim Coote on 27 Apr 2007