In the software world, there are often new technologies coming to market, new fields to explore, new techniques to use, etc. Filtering through these in itself can be a challenge. Deciding when to move forward with one in practical applications can be even harder. Many times as developers, we will be brought a problem that we can solve in a way we’ve heard about or read. This is when theoretical example attempts to meet practical implementation. We ask ourselves “Does [X] tool I read about recently solve this problem?” or “Would [Y] really work in my organization?”. This is where we can employ the proof of concept.
The everyday proof of concept (POC).
The proof of concept comes in all shapes and sizes. This article is not meant to discuss large-scale proofs of concept, but rather the everyday experiment carried out to learn, to show value or to prove behavior. The POC is often undertaken to move an idea out of the purely “idea stage” to a system or functionality shown to be viable or inviable for whatever goals were initially sought. A proof of concept can vary from something very small, like a time-boxed experiment to see if a new library can produce the same result as an in-house algorithm, all the way to whether a new architectural design can handle expected functional requirements for the coming business year.
Why do we need to do them?
It’s all about the last responsible moment. When planning work either as a team for the next release or as a pair for the next functional requirement of a story, we sometimes have no idea whether an idea is viable. This is a good place for the POC. We can plan, discuss, and research all we want, but until we see our code perform and interact with the system that it will eventually find its way in the midst of, the unknowns will linger. Executing a POC can help us eliminate numerous unknown implementation details as the software engineers, but more importantly can eliminate churn in finding out what the end result needs to look like to the customer or product owner.
A practical example.
I once worked on a project for a partner requiring a feature that from the outset seemed extremely complex. Early discussions led us to believe there would need to be significant planning and thought due to this complexity. Without going into details, this was an image processing pipeline that the team was concerned would take a large amount of time and effort to complete. Instead of spending days or possibly weeks planning out an architecture to pull off what we didn’t yet understand, we built a POC with free and open-source technology that demonstrated the primary functionality of the feature; all this in a matter of a single day.
In hindsight, we may have ended up with the very same solution had we done the initial planning and design as normal. However, what we didn’t have to do was sit through numerous sessions discussing what were for all practical purposes completely unknown. #winning
This is often the case with a POC. Even though you will sometimes end up at the same place, you may avoid periods of churn where something is tried and is written in such a way to be production ready, but as soon as it’s finished is thrown out the door because it’s not what the customer wants or is unable to meet functional requirements.
How do I decide when it's worth the time to do a POC?
This gets a little more challenging. We often think we have all the facts leading us to believe a POC is a waste of time. We then get to the end of our implementation with well-crafted, test-driven code and realize we were completely off the mark. In general, err on the side of doing a POC. Finish something quickly, and let others take a look at what you’ve done. There’s always going to be something to learn from this. When in doubt, as a colleague of mine always asks, ask yourself whether you “can see the shot?”. In other words, do you know the steps you’re going to take to implement this feature? Yes, the specific steps; no assumptions allowed here. If you do, go tell someone about it or draw it out for them (this someone would ideally be someone other than a pair if you’re pairing). Get it out in the open to give someone a chance to say ‘did you consider {insert comment that changes everything}?’.
If you are working with another team or another team will consume what you’re building, bring them in on the POC. Have them review the API contract you’re working on. Have them look at the data model you’re planning to put into the database. You name it. Use your resources to sanity check whenever you possibly can. Sometimes this can be a humbling experience. We as developers often like to figure it out on our own because “we know what we’re doing” – until we don’t. We’ve all had a situation when we finish work that was asked of us only to learn that an early assumption we made was invalid and/or false thus forcing us to rework what we just finished. Save yourself some time, take on whatever humility you can, and try to get necessary parties involved in each and every stage of your work.
Summary
This article is about the everyday work of a software engineer. This is about eliminating uncertainty that exists in nearly every piece of work we take on. In this sense, the POC should be used or at least considered by everyone at every stage of the game. Get something done quickly, see if it’s what was desired and if so, go back using what you’ve learned and drive it properly with tests given the newly found information.
This certainly won’t work with every organization or situation, but if you can, try it! By all means, let us know if you have any suggestions, and let us know how it goes when you put it into practice.
Craft well.
