Agile Zone is brought to you in partnership with:

In the course of his 30-year career, David Bernstein has trained more than 6,000 developers at hundreds of companies on how to improve their software design and construction. His company, Techniques of Design (http://www.techniquesofdesign.com), provides customized training, coaching and consulting to software developers and development teams around the world, enabling them to master essential practices, including Agile, Scrum, XP, test-driven development, design patterns and related techniques, for building high-quality software more rapidly. David is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

A Prototype is Not a Product

10.07.2010
| 4238 views |
  • submit to reddit

Sometimes I hear developers say that they are scared to build prototypes because their manager will make them ship it as a product. There is a big difference between a prototype and a product. A home builder wouldn’t mock up a house out of cardboard and then try to sell it so people could move in even though it might hold up on a dry summer’s night.

Prototypes help us understand what a product will be like or we can use them as a proof of concept to validate some of our assumptions about what we are building. But a prototype is not a product because it does not have the robustness or supportability of a product yet.

It is fine to take shortcuts when building a prototype. The purpose of a prototype is to elicit feedback from others or verify a design approach will work. When doing this we generally only concern ourselves with the “happy path” through our code. This is ok as long as we later go back and handle the error cases we missed.

Prototypes can also be sloppy. When we are trying out ideas that we aren’t sure are going to fly we may not have the most intention revealing names for our methods. The process of turning a prototype into a product should focus on making the code more robust and more supportable.

There is a very different mindset we use when building a prototype verses building a product. Prototypes can be quick and dirty; products must be robust. When we don’t pay attention to the productizing phase of development we end up driving the cost of ownership up significantly for the software we build.

References
Published at DZone with permission of David Bernstein, 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

Jason Erickson replied on Thu, 2010/10/07 - 3:53pm

Throw the prototype away. 

The problem for me has never been that the business people want to ship it - it's that they think it's almost done. All the work that is left to do is stuff that is basically invisible to them - so when you throw together a prototype in a week and they love it, they think it's just one more week and ship it, so you have to keep telling them every week, no, it's not ready and won't be ready for another few weeks, but then they ask again next week and you have to give them the same story.

 Now, you could say, "Let them ask.  As long as they don't try to ship it, that's fine."  That would be true if you (and all the other developers on the team) were as disciplined as robots, but the fact is, there is a lot of pressure to take a lot of shortcuts in the environment I just described.  If you have that discipline and the business people can handle it without growing to hate you, then good for you - prototype to your heart's content.

One approach that worked recently for me was that we had our design guy mock up a mobile application in Flash.  Flash wasn't going to work for the real application and everyone knew that, so there was no illusion that it was "mostly done."  It was exactly what you want a prototype to be - it let users/product managers know in a more concrete way what the user interaction was going to be like and they could feed back on that, and it was delivered very quickly.  It just didn't tempt people to say, "OK, that's great.  Let's polish it up before we ship it."

Michael Norton replied on Fri, 2010/10/08 - 5:43pm

I have used balsamic mockup to work through a wire-frame with our customers. This allows us to mock everything, talk about the flow of the application, and get feedback, but nobody thinks we are almost done. It even looks like everything was drawn by hand.

A prototype is an even better approach in many cases. The customer can actually use the software to try out different happy-path flows. But the trust and communication has to be present. Make it known at the onset that what you are doing is putting together a flimsy shell of a program that doesn't actually work and is nowhere near ready for delivery, but will give them a good feel for the application. And be careful not to polish the prototype too much.

Set expectations early and often.

Comment viewing options

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