Quick and dirty prototyping

Quietly, under the cover of darkness and the Business of Software forums, I've been spreading the corrupting CodeSnipers influence to pull more people into the inner circle. I'm honored to have our latest victim aboard. The author of Agile Project Planning... Dave Churchville. - Editor.

"Just tell me what you want and I'll build it!"

What programmer hasn't uttered those fateful words? The problem is that even though users often know what problem they have, they are rarely the best people to tell you how to solve it.

Enter the prototype. Developers either hate them or love them, depending on their experience. If you've ever built a sophisticated prototype that faithfully re-created the entire application, only to have it forced into production, you probably hate prototypes. Or worse, maybe no one even bothered to look at it!

Let me put this argument to rest once and for all. A prototype is a tool used to enable better communication about what a piece of software should do. As such, it's in the programmer's best interests to avoid confusing the customer into believing that it is the "real thing."

One simple way to get the communication you want without the "oops it went into production" problem is to use "quick and dirty" prototypes in the form of paper sketches or whiteboard drawings.

You can quickly experiment with several different user interface ideas and workflows on a pad of paper in the time it would take to build one half-baked implementation in code or even in a drawing tool.

If you have a customer in your location, often a session spent whiteboarding or doing a walkthrough of ideas on paper can help you get to the real problem being solved. Remote customers are a bit more challenging, but these can be resolved by using slightly more sophisticated prototypes that can be sent by email or used directly over the Web.

The keys to successful prototyping are to keep it simple, avoid using implementation technology to build the prototype, and above all, make it look like a prototype! Use the simplest tools that work for your situation, and remember the goal is communication.

So the next time you ask your customer to tell you what they want, try showing them something they can respond to. You'll be surprised at how much more information they can provide.

Simple HTML?

I prefer the whiteboard method when I can actually sit down with the client and discuss options. When you're remote though, it becomes quite a bit more difficult.

What do you think of simple HTML prototyping? For example, a ecommerce site which has one item in a fake cart, shows 2-3 products, has a static page for each checkout page, etc... I've found that one strength of this method is that it allows the customer to notice and figure out those style/layout things before there's too much code.

What do you think?

Napkin Look & Feel

Ah, so something along these lines... http://napkinlaf.sourceforge.net/#Snapshots?

Unfortunately, I haven't had an excuse to use it.

Worse is better

We just went through this experience. Someone built a quick prototype screen using VB studio. There was no code behind it. But when this prototype was shown to the execs, they thought that the programming was done, and they could start using it in couple of weeks.

The truth was that the whole thing needed to reside on the web - not a windows app. No database has been developed yet. Only the concept existed. Heck, the UI itself has changed completely from the prototype version - these execs are usually so focused on getting the UI done right.

6 months later, we're finally starting the customer acceptance tests.

Re: Worse is better

Koji,

I feel your pain. It's funny, when I first got started in software development, I loved to throw together quick prototypes to show a concept. It wasn't until I started getting burned by "Oh, this looks close to done, when can we have it", that I lost the taste for it.

Later, when I was a little wiser (or at least a little older), I figured out how to do "low-fidelity" prototyping that could still provoke thoughts and comments, without the distraction of seeming to be "done".

Ironically, the reverse is true for the actual software. No matter how "done" it might be under the covers, complete with great architecture, flexible and scalable design, and lightning fast performance, if it doesn't look great, customers tend to see the whole thing as shoddy.

So in a sense, the real progress chart for software development is a sliding scale from ugly or "sketchy" looking to snazzy and stylish.

Doh!

Dave Churchville
ExtremePlanner Software
http://www.extremeplanner.com

I had to laugh

I always prototype first... religiously. On one project years ago, my technical lead was, let's say, not the best tech lead I've ever had. I whipped up a static, graphical prototype in Paintshop Pro (hand-drawn buttons and all) and showed it to him. He asked me if it was ready to go. This from the guy supposedly in charge of the project.

Numbskulls aside, I still view rapid prototyping as perhaps the single most crucial technical step in the early phase of any non-trivial project. Much cheaper to change (or chuck) the design on paper.

Brian Moeskau
MyHomePoint.com - Powering the Modern Family