Rapid prototyping has worked wonderfully for me in projects. A lot of clients I've done projects for haven't had a lot of exposure to complex web apps so can't really visualize what they're going to get in the end. A rapid prototype helps them start picturing how it's going to work when they start using it, and not just how it looks on paper. When specs are solely on paper the danger is that it's either so high-level it leaves out crucial details, or that it's so detailed it just reads like computer-gobbledygook to them and they can't pay attention to it. It's way too difficult to describe computer programs strictly on paper, and much much more difficult for a non-programmer to describe or understand those specs. A visual tool cuts away greatly at that learning curve.

It's saved a lot of time, headache and (most importantly) money by implementing prototypes with HTML and Javascript and allowing the client to point to what they like, and what they don't like. Of course, sometimes the client uses the opportunity to make bad suggestions, or doesn't understand that the programming still needs to be done, and so on. But that's a lot easier to explain than delivering the project the week it's due and having to tell them that it'll take another few weeks to make a change that they want which they think'll be small but it really isn't. Especially if it's a feature that they expected to be in there in the first place, but you knew that you'd already said in your gobbledygook that it wouldn't be. I'd rather go through the headache of explaining to my client what a rapid prototype is, than have to hurriedly patch beautiful code because last minute changes blew the entire design.

Rapide prototying has also been a good CYA tool, since if the client doesn't like what you deliver, you can always compare to the prototype and show that their requests for changes are really beyond the original scope of the project. It helps put a hard stop to the project whereas if specs were too loose, or weren't understood by both parties, it's a lot harder for a client to feel like they got what they asked for and for a developer to feel like they're done.

When your client says "I want ecommerce" and you build them a simple shopping cart and they thought you were going to build them the next amazon.com...well, that's not good for anybody.

In reply to Re: Is Rapid prototyping working for anyone? by koolade
in thread Is Rapid prototyping working for anyone? by C-Keen

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.