Over a million developers have joined DZone.

The Perils Of A Polished Prototype

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

Protoypes are good. Well I think so. They give you a better idea of how an application should hang together, where the abstractions are, where there are opportunities for refactoring and re-use.

But are there downsides? The classic one is that a prototype sometimes becomes the production code.

The other day I received a diagram from a colleague of mine, Tay. It was one of the worst diagrams I had ever seen. Not because it wasn’t clear, because it was. Not because of what the diagram was representing, because that was also very well thought out. No. It was bad because of the presentation. The diagram had been drawn up in Microsoft Paint, on an old Windows XP machine. As we hadn’t used Windows XP for years I suspected that Tay had actually gone out of his way to find an old Win XP machine simply so that he could use an old version of MS Paint. I do not know if you have ever tried drawing a diagram in MS Paint on a Win XP machine, but my recommendation? Don’t.

Anyway I went to Tay and asked him why on earth he had drawn the diagram that way. He had some of the best diagramming tools in the world available to him so why on earth use paint!

His reply? He didn’t want to give the impression that it was a finished idea. It still needed a lot of work thinking through some of the parts of the system we were going to build, which the diagram represented. By making the diagram look like it was half finished, and written on the back of a paper napkin, after a rather heavy lunch, he wouldn’t make anyone think that it was finished.

So I’m sure you can see where this is going. If you have a prototype and you do not want that prototype to become production code (which it could do if that was the plan but that is a story for another day), then polish is bad. If you have a polished prototype, no matter what you say, then the people you are showing the prototype to will think it is the finished article. After all the user interface is the system right?. It comes back, in the end to mental models and managing expectation. By providing a polished prototype you are up-managing someone’s expectations and giving the impression that your work here is done.

So when I build a prototype I let some of the bits hang out. Let it crash now and again. If the product is truly a prototype and not an alpha version of the product then maybe you should avoid making it look too polished.

Have you suffered from making a prototype too polished? I would love to know so please feel free to leave a comment.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of Chris Odell, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}