The company where I’m working right now likes to invest resources in Proof of Concept, or POC, projects. The intent is admirable enough – prove that a concept/process/technology/etc. works by spiking some small portion of it and evaluating the results.
This sound really great in theory. But if it was all gravy I wouldn’t be writing this post. So here’s the rub – it has to be crystal clear exactly what is being proved. If management is vague and just wants to see some documents or a demo, the risk in moving from POC to a production project becomes very high.
Let’s look at an example. A project that I’m involved in right now is proving that legacy code can be taken from the outdated, purchased system with a proprietary-language and migrate core functionality to .NET – specifically WCF services. Sounds simple enough, right?
The code in the existing system is a tangled mess, as one might expect, and all the logic is buried in the 3GL-type forms. The database is also a rat’s nest and the converted code must use the legacy database.
The project is moving along and things are working, but an all too common dismissal for the quality of code that’s being written is “hey, it’s POC code”, which leads me to the point of this post.
Because the goal of this POC is only to see that it is possible to move legacy code to C# on WCF, it’s acceptable to the team that the code being written is a house of cards. It is so brittle and hard to test that the smallest change could send it tumbling down. My worst fear, however, is the possibility that a number of bugs and issues that result from a change could go undetected.
I don’t believe, in this example, that the concept is truly getting proved. By not specifying that the project should prove the concept in a manageable way, following established practices for creating highly cohesive and loosely coupled code that is testable and continuously integrated with automated testing, the project sponsors have essentially said “build a house of cards” – hence the attitude that quality doesn’t matter because it’s just POC code.
It’s my opinion that if one wants to prove a concept like the one I’ve been talking about, it has to be proven to be a viable solution in some real world capacity. At the end of the project, the POC may be deemed a success but few will know if it is actually possible to build with a sense of confidence and stability. The other angle is that management may expect that since the POC has already been completed, it shouldn’t take much more time to get it ready for prime-time, which is this case would be a fantasy.
In conclusion, when drafting POC project document, make sure to specify some degree of real-world expectations. Build in the extra time to ensure that the concept can be built to withstand the pressures of real-world change. Otherwise, you may not know the truth until you’ve either deployed a fragile system or found yourself sinking more resources into a project than you ever would have expected. This may not be applicable to the smaller projects, but for larger ones, I think it’s worth the investment.
Corey Coogan 