Agile Zone is brought to you in partnership with:

I wrote my first program in Z80A when I was 14 on a ZX Spectrum and ever since I have been hooked. I love writing code of any flavour as well as being passionate about the coding process. I have worked professionally in the software industry for the last 15 years using Microsoft Technologies, and I code at night in PHP, HTML, Javascript and CSS. Chris is a DZone MVB and is not an employee of DZone and has posted 31 posts at DZone. You can read more from them at their website. View Full User Profile

The Perils Of A Polished Prototype

04.03.2014
| 16917 views |
  • submit to reddit

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.

Published at DZone with permission of Chris Odell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Walt Stoneburner replied on Sat, 2014/07/12 - 7:32pm

A technical writer I know suffers from this same problem; his solution? Use an ugly font and make text in a dark, ugly purple color, clearly conveying this-isn't-done.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.