>> 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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
