Rant on Rapid Prototyping of Software

<rant>

I tend to vote for throwaway prototypes.  Something whose initial purpose is to test something, whose design doesn't really matter.  Where the prototype is not intended to become the final product.  My reasoning is that organized code actually distracts from getting the goal done.

Why?  because a prototype is supposed to answer some form of feasibility question.  If the prototype is designed to become the entire system, then something's wrong.  It could, in retrospect, become the final product - but this shouldn't be planned.

Why again?  agility.  If you're testing the stability of  the algorithm of a physical system, do you need to run it in the final application?  Most likely no - you know the performance characteristics of the algorithm and any computational limits that are imposed.  The goal is to write, as quickly as possible, an application to display the results and to set up the system with harsher conditions than what is expected in the final application.

Expanding on this idea - if the code is expected to be used as-is - maybe the programmer might spend extra time organizing the code, making it legible, documenting.  Actually, a prototype just needs code and a person that understands it.  Organization is over-rated - whatever gets the code written the fastest is most important (why use accessor functions when variables can be directly accessed?  why comment if the algorithm will be quickly swapped out?  why worry about aesthetics of the visualization when the goal is to observe stable and correct behaviour?

Again - let's consider a user-interface.  A very touchy subject, as reading a user's mind and knowing what's best for them is actually harder than it seems.  A good user interface does not need a manual as it is intuitive  (that's a comment on the current state of UIs though - if training on a UI is needed - something's wrong in my opinion).  I believe it more to be a hit or miss situation - UI will either be good or bad.  It's like throwing plenty of things at a wall and seeing what sticks.  Now - if we create a prototype designed to evolve into the final product, then there is a layer of organization which implies assumptions.  There is structure.  There is documentation.  Comments.  Plenty of work that has the real potential of actually being trashed rather than seeing the light of day.  It should be done as fast as possible just to ensure that users can test.  It doesn't even need real data - just a realistic progression so that users can judge of the ease of use.

What could change in a UI?  Buttons need to shift around.  Sub-windows?  Lists?  Custom controls?  Special effects?  Each of these could be added and removed at will.  A good UI should have several test versions.

Then - what happens when a prototype has discovered the path to follow?  We pillage what's salvageable and good, as quickly as possible.  We document.  We comment.  We organize.  And tackle the next challenge.

Isn't a small amount of spaghetti code to prove a concept worth it if concepts get validated or disproved quickly as opposed to developing a large framework?

As in quickly - a prototype should not take more than 4 hours.  It should be focused.  If the prototype includes building a functional version of everything - then maybe you aren't building a prototype...

</rant>