Usually coders put together a prototype and then develop the final version by either (1) fixing the prototype, or (2) developing it from scratch. When time becomes an issue, it's natural for teams to choose #1 instead of #2. But since the prototype is rarely designed with the exact use in mind (or even with things like security) that means lots of stuff to fix and design-around.
Using a good framework, keeping a sense of the long-term architecture needed and following agile/DRY practices cuts down on the difference between prototypes and final products, and is one of the reason (imho) for the popularity of Rails and the 37Signals approach to web development. Most people just flail though.
Using a good framework, keeping a sense of the long-term architecture needed and following agile/DRY practices cuts down on the difference between prototypes and final products, and is one of the reason (imho) for the popularity of Rails and the 37Signals approach to web development. Most people just flail though.