Art of PoC
Proof of concept (PoC) vs prototyping vs spike!!!!
Frankly to me all are same and throughout this article I will stick to the term PoC.
Looking up for definition of PoC I stumbled upon wikipedia which says,
“ Proof of concept (PoC) is a realization of a certain method or idea in order to demonstrate its feasibility, or a demonstration in principle with the aim of verifying that some concept or theory has practical potential.”
Phew!!! Thats a very heavy definition.
To me PoC is something which proves if stuff works or not. Anything beyond this and the whole fun around PoC gets sucked out.
A new project is about start and it comes with its own package of unknowns. 3rd party integrations? Explore a new graph based db? Flink vs Spark?
How does one estimate these unknowns? Obviously one can spend eternity in answering these questions but clients really don’t care about your anxieties.
They just care about time. And making blind assumptions without any validation can make or break a project.
Thats where PoCs are invaluable to quickly and efficiently validate our assumptions and gain clarity in regards to making important desciosns.
- Timebox — Based on my experience, if a PoC extends beyond one week (5 working days), then either we are trying to prove too many things as part of this one PoC or the thing we are trying to prove is….not PoC worthy and deserves its own project timeline. PoCs are supposed to be quick and very laser-focused. One week is my rule of thumb.
- Document — This aspect is something developer is oblivious of when he is busy writing code and debugging stuff at 3X speed. But once the PoC is complete and everyone is happy, the learnings are almost everytime lost and nobody cares. These learnings can apply to multiple projects and save a lot of time for others and a decent documentation (not a very formatted and extensive one) which covers all the learnings is worth saving. Its not just enough to document the learnings but the hacks and tricks you needed to make for the PoC to work like editing some configuration parameter, tweaking some environment variable, etc. The online resources you have referred to is something worth documenting. I can’t stress enough on this point but documentation is must.
- Write messy working code but not that messy — Atleast in most of the projects I was involved in, the code used in PoC usually ends up being reused as the base code for the actual project. So it actually makes sense to write some comments and have atleast a basic structure and good naming conventions which can allow others to read and debug the code. I am okay with one gigantic main method but please don’t make the code unreadable with variable names like x1, t2, etc.
- Commit the code — Once a PoC is complete it contains not just one java class file but multiple other files like scripts, build files, docker files, etc. Its important to commit all these files in code repo instead of keeping it in our personal laptop and when asked for the code after 6 months, doing crazy searches across all your drives because as devs we usually end up with file naming conventions like Test1.java, file1.sh, etc.
- Demo — Now that you have completed the PoC and discussed the findings with your architect which helped him conclude, you feel satisfied and happy. Want to feel proud, then share the findings with the team as part of a demo. Showcase the whole working thing to the team in a live session and enjoy as others gasp at the magic you have created in just few days. But its not just about you feeling proud. Its making sure others validate of the approach you took and come up with some smart/creative ideas which can take your code to next level. A discussion can generate many cool ideas as opposed to others reviewing your document in silos.
Hope whatever I have covered makes sense and would love to hear others thoughts.
Also, please don’t forget to have fun. At the end of the day its awesome to see something running and feeling a few points smarter.
Sarthak Kumar Barik
Solution Architect
