The five laws of prototypes, minus four

Tim Weaver: "Here are my five laws of prototypes that I've found to be universally true."

Very far from universal, Tim. All of the laws except the first essentially say, "The prototype will become the production system." This may be universally true in Tim's experience, but for me it's actually true only in a minority of cases. Perhaps I've been lucky. Perhaps Tim's been unlucky.

The first prototype I worked on was some seven years ago -- my then company's first major Windows product, and first MFC project. We did a quick prototype to learn MFC, to get the user interface agreed, and to have something to demonstrate at trade shows. It was a horrific piece of code, full of abandoned experiments and performance-murdering simplifications. (By the time it was completed it took minutes to start up.) We threw it away and thanked providence for the lessons learned. If we had carried forward any of the poor coding practices or made the performance worse, in accordance with Tim's laws 2 and 3, we wouldn't have had a product. If we hadn't done the prototype at all, we would have made all those disastrous mistakes on the production codebase, and then it would have been really hard to excise them.

Another salutary example came at my next company, where I was asked to prototype a user interface for a significantly more complex feature than we had before. Again the prototyping was done using MFC and again it was full of hideous hacks. If I remember rightly, the view class got so mangled that I ended up #defining the MFC document type to point to a member function of the view -- truly unspeakable stuff. Did the production developers obey law 2 and replicate my poor coding practices? I think not. Did the prototype obey law 4 and live forever? No, it died as soon as the production code reached UI scaffolding. Did the production developers obey law 5 and reuse my snazzy timeline control? Possibly, but then it was actually a good fit, because I'd had to throw away the "easy" option because it didn't implement the behaviour I needed. I'm pretty sure they didn't reuse my other controls! I had a similar experience on a smaller Web-based prototype -- the original wasn't so bad this time, but we still started over when we came to do the real thing.

Finally, an example of prototyping at White Carbon. About 18 months ago I prototyped a Gantt chart style planning UI. Performance was poor and the code was deeply confusing. Later I was asked to prototype a Gantt chart UI for historical views of activity within a lab. This time around, I obeyed all of Tim's laws, lifting cryptic code wholesale from the earlier prototype and kludging it into working. Why? Because this was just another prototype. It didn't deserve care and attention. I later came to develop the production UI, and the lessons I'd learned about flicker, speed and code structure meant that I was able to product a component I'm pretty pleased with in terms of usability, clarity, functionality, aesthetics and maintainability. We simply junked that hateful prototype and every line of code that was in it: laws 2, 3, 4 and 5 didn't apply.

So while Tim's laws of prototypes may well reflect one experience, they're very far from universal. Indeed in my experience they represent the minority of cases.

So do take Tim's laws as well-tested warnings of common mistakes that must be avoided, but don't believe that they're inevitable. Don't fall into the trap of refusing to prototype because you think the prototype is bound to taint the production code: honestly, it's better to make your worst mistakes quickly and where you can throw them away. But it is up to you to be strong, to make sure that you don't become a victim of Tim's laws. Make it very clear that the prototype cannot go forward. Make the prototype so bad that it can't go forward. Make sure that you have sufficient influence on the project that you can ensure that your prototype's bad coding practices don't get picked up.

Tim's laws are a great way to summarise the dangerous pressures that a prototype puts on production code. But they don't need to be true. And if they do come true on your project, you may have only yourself to blame.