Over a million developers have joined DZone.

The Perils Of A Polished Prototype

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


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 }}