Kenneth Fisher strikes a chord:
If your POC does not follow your companies best practices and standards then it is not a valid POC.
There are way to many settings that will change it’s performance, cause security issues, etc. On top of that, almost every POC I’ve ever seen ends up becoming the test environment if not the actual production environment. So all of those little compromises end up in your actual, non POC environment because it’s way too much work to fix them now. You should have said something when we set this up.
To use one of my favorite lines, “Short answer: yes with an if; long answer: no with a but.”
Before I get to the answer, I do want to differentiate between a proof of concept and a pilot. The idea of a proof of concept is to see if I can make this thing work. Can I get these two processes to talk to each other? Can I build a website which accepts user input and displays something? Can I get this idea from my head into code? Can I process 500,000 records per second using our existing hardware? One important thing about a proof of concept is that it always has the possibility of failure. “No” is a valid answer here based on the conditions. By contrast, a pilot is a starter for the full project. You might work with one business unit instead of all of them, migrate a small amount of traffic to the new system, or only handle data from a single branch office. Also, you want that answer as fast as is reasonable so that your business decision-makers can make business decisions on that information. By contrast, when we do a pilot, we already know the answer is yes; we just need to build it out and answer the technical details along the way.
Returning to the line above: Yes, I agree with Kenneth if your company lacks the discipline to differentiate between proofs of concept and pilots (and that’s not as denigrating a remark as it sounds…though it’s somewhat denigrating). No, do not follow the same practices for a proof of concept that you would for a full product, but you need to ensure that code gets destroyed and you start over with new code which does follow those practices.
Excellent point on the difference between a proof of concept and a pilot. That said, I can’t tell you how many times I’ve seen a true POC (can I get this to work) get thrown into production. And 9/10 they have taken shortcuts because they are only testing to see if it will work. And of course now those shortcuts are in production and then over time I start getting “Well, we did it here, why can’t I do it there.”
Yeah, that’s why I had to break out the Reverend Lovejoy response. There’s definitely an “is versus ought” aspect to this, where at many (most?) organizations, “You have a proof of concept” suddenly becomes “You have code in production” because the business people see proof of concept and ask, “So, when can we use it?” It does take a lot of organizational discipline to use proofs of concept correctly, so for people who know they are in companies lacking that discipline, I agree with you: treat everything as a full-blown project. Unfortunately, that also tends to slow things down but that’s the cost associated with a lack of discipline.