How do you move from the Proof of Concept phase to working on a production-ready solution?

Question

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?

Answer 1

If the code works, use it. Spend a little bit of time refactoring the messiest parts in order to ease future maintenance. But don't fall into the trap of building a new system from scratch.

Answer 2

For me it would depend on how sloppy my POC was. If it is something I would be ashamed to pass onto another developer, I would rewrite it. Otherwise, just go with what you got.

Answer 3

Refactor the existing code into the solution.

Answer 4

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...

Answer 5

Throw away everything from the proof of concept except for the lessons learned, and, possibly, some minor code fragments such as calculations etc.

Proof of concept applications should never be more than just the bare minimum to see if the technology in question will work and to start testing some of the boundary conditions.

Once done you are free to redesign the application with your new found knowledge.