I’m working on a project that’s been accepted as a proof of concept and is now on the schedule as an actual production project. I’m curious how others approach this transition.
I’ve heard from various sources that when a project starts as a proof of concept it’s often a good idea to trash all of the code written during that rapidly-evolving phase and essentially to start over with a clean slate, relying on what you learned from the conceptual phase but without working to clean up the potentially messy code that you wrote the first time around. Kind of the programming version of ‘throw away the first copy of that angry email you’re about to send and start all over’ theory.
I’ve done it this was in the past and I’ve also refactored the conceptual code to use in production, but since I’m in the transition phase for a new project I wanted to get an idea how others do this. Obviously a lot depends on the project itself, and on the conceptual code (if what you generated works but won’t scale for example, it’s probably best to start afresh, but if you have a very compressed timeline for the project you might be forced to build on what you’ve already written).
That said, if all things were equal what would you all choose as an approach?
As you already kind of hinted at, the answer is, ‘It Depends’
Starting over is good because you can help trim out the stuff that was added while you were initially working out the kinks but isn’t really needed.
It also gives you a chance to give more consideration to how you want the architecture to be — without already being dependent on how the proof-of-concept was written…
In practice, though, unless you’re in the business of selling the software to the outside world, building upon the prototype is pretty commonplace. Just don’t get into the habit of thinking ‘I’ll fix it later’ if you run into some code that smells or seems like it could be done in a better way…