Posted on Leave a comment

The Proof of Concept

One valuable tool I wish I had realized was at my disposal earlier in my career is the proof of concept. I remember jumping into large projects intent on implementing the latest and greatest library, only to discover that I couldn’t get it to work because I didn’t really grasp how it worked. Having a smaller space to work out the various ways to implement a framework or a new library is probably one of the easier ways to dive in and start getting your feet wet without the pain of an existing application’s overhead.

Ideally the proof of concept is small enough that you can really exercise the functionality you expect, but also non-trivial enough to prove out that it can meet your specific use case. For instance, I’ve bene playing with feature toggling lately because I need to plug it into an existing monolithic application. Feature toggling isn’t necessarily that difficult when you have a clean architecture and you’re starting from scratch, but when you’re approaching an older codebase that has built up over time and was never designed for feature-based development, you don’t want to just go in there without having first worked out a good plan. In my opinion, the best way to do that is with a proof of concept.

Additionally, it can serve as a roadmap or testing ground when you do finally dive into that larger codebase to start implementing the library or framework. If you get stuck in the big codebase, go back to your POC and play with it. Experiment until you can recreate the roadblock, and then using the POC work your way out of it.

A POC is also an excellent way to communicate your technical intent. You can usually get one created in less than a week (sometimes less than a day) and because it’s small and focused, it gives you an excellent basis for discussion with your development team. It’s usually ideal for a team review because it does exactly what you intend, without all the overhead of the existing solution.

Next time you consider trying out a new framework or library in your existing codebase, think about creating a proof of concept. Even if it is a throwaway program, implementing it will add to your technical knowledge and give you something to reference for the future.

Happy coding!

Leave a Reply