This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: On Prototypes
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Prototypes. They're everywhere. Sometimes they grow into full-fledged systems. Sometimes they're thrown away. But they can be considered a project in their own right. I've decided to write this entry after reading Fabrice's thoughts on the same subject. Before getting into my own thoughts on the matter, I'd like to quickly sum up the main points I found there, including the comments posted.
The main issue originally revolved around web apps, and whether HTML or ASP.NET should be used for prototypes. Powerpoint, Visio, Paper - yes that stuff that comes out of printers, Photoshop, Illustrator, and Denim were all brought up. Arguments for and against were made. Before I pick a side, I thought I'd return to the basics.
A prototype, by definition, should be thrown away. The lessons learned, obviously, should not.
I bring this point up as it is the most basic. When thinking about prototypes, the last thing that should concern us is if we can "reuse" pieces of it for the actual system. Now, if the point of the prototype is to learn, and learning is most facilitated by short feedback loops (tons of research back this up, think pavlov), we should be looking for the "technology" that allows for the quickest feedback.
What do I mean by feedback ? What the client thinks about what we're doing. And what's the fastest form of "do something, get feedback" ? Talking. What we need is a way to actually DO the prototype WHILE talking to the client. This pretty much reduces the number of contending technologies down to 1. Paper.
Paper prototyping, when done well, brings to light SO many issues and unspoken assumptions in SO little time, that, from my experience, it just doesn't make sense to go any other route. There is so much information out there on paper prototyping that I can't even begin to list it here. Just google it.
So, how can paper prototyping be done well ? Well, it requires preparation, and, obviously, lots of paper. Plan for about a 1 hour sessions at a time with the client, no more. These sessions are VERY tiring. If possible, try to get someone to write down everything that came up during the session, and what resolutions were reached. This person should not be involved in the session beyond being an observer.
Now, let's consider the alternative. Using a computer + some software, be it Visio, Photoshop, whatever. The problem with these approaches is that we get to focused on what we're building, and lose focus of the lessons we should be learning. These approaches obviously increase the time between a decision we make about the system, and getting the client's reaction. It therefore also increases the time we waste when we get a decision wrong.
The Agile world has already come to this conclusion and makes every attempt to get a real, live customer/client/user on-site for the development of the actual system. When building actual systems, obviously, paper can't be used. But where it can, and it's most appropriate, it should.
To sum up, when a prototype is done, we should know more about the real system that we're building than when we started. Short feedback loops with our clients is what gives us the most information. And paper is the medium most suited to short feedback loops when dealing with prototypes.
Previous Topic
