launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

>> On the one hand I can understand, however I think one of the great
>> principles of this kind of work is the chance to produce a real prototype.
>> Any prototype should be trashed once complete. In this way you're
>> encouraged to perhaps go out on a limb more during this stage since you're
>> not going to be stuck with any decisions made except the UI interactions.
>> Secondly, you don't get attached to the code so you won't spend the time to
>> make it more robust and resilient since "it's going to turn into production
>> code".
>>
> 
> I have to agree with Rick.  The moment you start thinking about coding
> more than prototyping it defeats the gain to be had from doing
> prototypes first.  Why not just start coding? :)
> 

I agree, there's two distinct mindsets in prototyping vs development.
With prototyping, you take shortcuts, do the least possible to get
something "working", avoid worrying too much about design, reusability,
resiliance etc. And you tend to throw away most of what you do for sure.
But, if you use similar technologies to what you develop on to deliver
the prototype, there's a good chance that valuable nuggets will emerge
that can be reworked into the production work when it commences. There
may be some core logic that is needed to implement the business rules to
show off in the prototype and all you need to do is make it more robust
and repackage for example.

The other main point is that if we can leverage the tooling and
facilities from the technology stack we develop under in order to avoid
too much hand coding and other manual/tedious effort, that is great too.
Sure, what's done will likely be discarded, but it's faster and easier
to come up with in the first place.