This is part 3 of 3 part series about MVPs and PoCs
Part 1 - Difference between MVP and PoC
Part 2 - MVP from Software Engineering perspective
Part 3 - How to run PoCs - Software Engineering perspective - this article
What’s a PoC from Software Engineering Perspective
In my own words:
A Proof of Concept is kind of a prototype of your application/service/website. The goal of a Proof Of Concept is not to deliver working functionality. Rather, it is a way to test if the project is technically feasible. In a more general description, you could also say that the goal of Proof of Concept is to de-risk the project by implementing all the risky technologies and architectures that the developer doesn’t know yet if it’s possible to implement or not. In this article, I will focus only on technical risks and development challenges with PoCs.
Multiple times, when you develop new functionality or create a new webservice or an application, you don’t know if everything that you or your Product Owner envision is possible. The goal of a PoC is to decrease that risk by validating that all the technological challenges are achieveable. By running one or more Proof of Concepts, you diminish the risk of such a project failing to be delivered.
Most common mistakes with PoCs
Implementing random stuff with the new shiny framework and calling it a PoC
Because we, developers, mostly work with frameworks and services, we often need to learn new framework or an SDK. For many PoCs that I’ve run in the past, I focused too much on the framework and not enough on the big picture. While doing PoCs, I was mostly afraid that I won’t be able to finish the application using that new shiny framework. It is a valid point of course to prove yourself against the task. Also, sometimes I would randomly implement few requested features in the new framework, to see if everything works. I would later call it Proof of Concept and report that it was succesful. This is not how Proof of Concept works. When implementing the PoC, you should focus on areas that pose the highest risk to the project or are critical to the project’s success. I will elaborate on this later.
Using PoC in production
Proof of Concept is not meant to be used in production. Many companies have hard time leaving PoC behind and force developers to develop on top of PoC. Proof of Concept should be thrown into trash after it proved or disproved the assumptions. Projects that leave PoC often end up in bad architecture and technical debt that is very difficult and costly to eliminate. I recommend to agree upfront with your Product Owner or an Engineering Manager, that the PoC won’t be later used in production. Such an agreement might help prevent disagreements and disappointments later in the development process.
How to run successful PoC
1. Define the PoC
Whether it’s rewriting an app in a new technology or introducing new tool to your company, the PoC should have a goal. You should know why you are running a PoC, and what value the implementation will give to you or your company.
2. Create list of risks and sort it from highest to lowest
Create a list of risks or points that a PoC should eliminate or validate. The list should contain elements that you or your team are not comfortable with implementing, or not sure if the technology is there to achieve what you want. The risks are usually technology related and are quite subjective to the team that will be validating them. Some examples of risks/assumptions to validate (some of those are taken from the projects I ran):
- new architecture will scale well to 1000 machines
- new tax service will be able to communicate with payments system and get all the data needed for processing taxes
- Linux application will be able to print tickets with the same layout as Windows application
- Linux application will be able to unlock the screen automatically when someone approaches the computer
3. Validate all the assumptions using lowest-cost possible
Next step is validating the assumptions or removing risks by providing an implementation of the assumption. The implementatino itself proves that there is no risk associated with the concern. If there was a risk, you would probably not be able to implement the technical challenge or the functionality you pointed as risk.
You always start from the riskiest assumption. If you encounter a risk that cannot be eliminated or circumvented, you have just proven, that the project cannot be finished with the initial assumptions. As you go and validate all the risks from the highest to lowest, you are diminishing the chance, that the project will fail at a later stage.
You can also ask your colleagues from other teams or look up solutions on the internet. Perhaps someone else has proven that your problem is solvable. In this case, you have eliminated one of the risks without wasting any time on development! This is very efficient way to eliminate risks. You have to be careful, though, as online solutions might not work in your context. It’s best to validate the online solution in your company anyway, to make sure that it really solves the concern that you had.
E.g. for the validation of the tax system integration with payments system from the previous paragraph, I would implement a very simple client that can communicate and prove and we can fetch all the data that we need. This is especially helpful in environments where documentation is lacking and you are never sure, whether the other service really provides the data that you need.
Don’t forget to use lowest-possible effort to validate the risks. You should spend a minimal amount of time on validating the assumptions. It is not the point of the PoC to provide a production-ready functionality. The only goal is to see, if the implementation is technically possible. This means that you should not care about beautiful architecture and focus on technical feasibility.
Even if something is technically possible, sometimes it might take too long to implement. In this case, you should treat it the same way as if the solution was not possible. As Software Engineers we need to be pragmatic and cannot propose a solution that will take forever to implement.
4. Conclude the PoC
At this point, you have pushed all the known risks to the corner and you are ready to start creating/rewriting/reachitecting this new shiny thing. You have proven that there are no technical obstacles to the new solution and that you are able to deal with most of the challenges that might happen in the next stages. Of course, this does not mean that the project will be risk-free. There are many other factors that can cause problems and obstacles in later phases of the development. However, at this stage you can safely start the work, knowing that most of the biggest problems have been solved already.