When I was at university, a teacher would ask me to test technologies he had read about in some article or other. In our profession, new tools may come up, tools that might make it easier (or more difficult) to undertake our tasks. Sometimes, we’re the ones requesting something new because we’re curious about it but, in other cases, it’s the client that requests something, since they believe the change might be beneficial for the project we’re working on. We always need to bear in mind that, with each emerging technology, such as Terraform, React, Angular or Kubernetes, there are always developers who think they might make things easier for us or who even use these technologies to come up with solutions to problems we hadn’t thought about at the beginning.
It’s completely normal to find someone who has already implemented a beneficial new library or framework to a problem we’re having right now, but this means learning yet another tool. This might be problematic, because we need to make decisions to see whether or not it’s feasible to include this tool in our implementations. Bearing all this in mind, the following article is a brief introduction to the task of creating a proof of concept and explains how to survive it (or, at least, how to suffer less).
Proof of Concept
A Proof of Concept (PoC) may have two different results:
- If the answer is “Yes” –> We actually say “Yes, in case…”
- If the answer is “No” –> We actually say “No, because…”
However, in both cases, we need to establish an objective. The biggest problem of any PoC arises when we haven’t agreed on an objective and a time span.
When we’re faced with new technologies or tools, we also need to face the uncertainty of not knowing if they’re going to be useful. But, in many cases, we only know about certain characteristics of the tool, such as:
- It enables Kubernetes implementation during production.
Besides, many times, we know the nature of the problem, since we’ve already encountered it, but we don’t really know how we can make things easier. So we just enter a comfort zone, until someone or something makes us see things differently, and that’s when we feel curious about implementing a new solution.
We need to understand the problem to be solved and figure out how much it will cost for our business (in terms of time, money and effort). This way, we can set an objective. In case we can’t establish one particular objective, we’ll never know if the PoC was successful or not, or if we got to where we wanted to. This is why, from the very beginning, it’s important to set a goal that will allow us to know whether we’ve solved the problem with a new tool.
In case we don’t set a date, the PoC can go on indefinitely, until we reach our objective. However, in this case we don’t really know how much time the implementation might take or when we’ll be able to discover something new and, at the same time, we can’t really produce clear results.
How to Create an Efficient PoC
Now that we know that the objective and the time span are two key variables, let’s take a look at two different situations that might require a PoC.
I have a problem affecting my business and I don’t know how to solve it. This “new” situation might help me solve time-consuming tasks.
We need to go the extra mile and work in state of the art. We should also know how other companies are solving the same issue and which tools they use to implement their solutions.
We believe in what the tool has to offer and we don’t take into account the market, which is a decisive factor.
Now well, if we take into account everything that’s been said, the steps for a successful PoC should be the following:
- Defining General Objectives
We understand the problem and we establish what it is we need to solve. This allows us to know how far we must go with our PoC.
- Defining the Tools, Libraries and Frameworks to Try Out
After analyzing the new tool or tools, we present the state of the art and we answer questions such as:
- Does this come with support?
- Is it an active community?
- When was the tool’s last update and how often are they implemented?
- Do other companies use it?
- Does it come with relevant files to solve any problems at the time of the implementation?
- Defining a Time Span and Specific Objectives and Starting to Plan
At this stage, we need to connect tests to questions like: “I need this tool to do this, so how can I solve it?”
It’s a little bit abstract, but it works. This way, we get specific objectives and we can solve doubts that come with the planning. Besides, if we establish certain dates, we can understand the effort we’ll have to make and the learning curve for others.
It’s quite common for either of these specific objectives to appear: How should we install it? How is it set?
The Importance of PoC
If you don’t manage to establish some of the specific objectives or the general one, then don’t worry, it’s part of the PoC. Knowing whether you can establish it and, at the same time, knowing why you can or can’t do it allows you to have an idea about its feasibility. At this point, many uncertainties should have been solved and we should have an idea of whether it’s worth making the effort.
But if you do manage to set all the specific objectives and the general one, you should offer an evidence-based answer. This is why you should take into account the implementation effort and the cost of changing to a different tool, and you should also prepare a draft on how to do the implementation. It’s the same as when you plan for a product: you need to know which skills are required, which ones you already have and which ones would be beneficial to give the implementation the maintenance it requires.
In any case, a PoC will always help you grow, because it allows you to step out of your comfort zone and broaden your knowledge about technologies other companies are using. So I wonder: do you place value on PoC in your projects?