Goals
Find out if we can solve the problem at all
If we have a problem where we don't know if we can solve it, a prototype allows us to attempt it with the least risk.
We need to try something to be sure we can solve it, and the business needs to know this because the solution normally results in a return for the business.
It's a risk we take ahead of time, to mitigate the larger risks later. We are trading a small amount of time now, for a huge saving and a big confidence boost in knowing we can execute a solution well.
Find out if we can do it in good time
After a prototype, we can see if the final solution is worth it. Will it cost too much time and money?
How far will the final solution be from the prototype?
Always be aware of the difference between the best possible way of executing the solution and the state of the prototype. This distance is how far you need to go after you have proven you can make it work.
Find out if we have the skills in our team
Can we find the people we need with the skills to execute the prototype, but more importantly, the final solution.
Sometimes we find hidden skills in our team that lets us solve something, in a non-standard way. Something our regular development process might miss.
Think of prototyping like a business sanctioned hackathon with a specific goal.
Dangers
Technical Debt
The prototype is not the final solution, every step we take, and every line of code written is technical debt, for which we can assume all of this might not be used.
We must think about how we might deploy a final solution, and who will maintain it during prototyping, so the distance between this and the final product is shorter. We must do ourselves a favor in the future.
Your solutions should be Cattle and Not Pets.
Always maintain a technical debt log, where the business can see it. You must make any stakeholders aware that a prototype is just that, and not an MVP or other directly usable solution. The business will try. This is a very dangerous thing. Stand your ground.
Temporary Permanence
If a prototype does end up being used in production there is a real danger that this temporary solution may end up being a permanent part of the infrastructure. Though this sounds exciting for a business addicted to features, this means that additional infrastructure will spring up around it to deal with the difference between the prototype and the correct solution. API, operations, support teams, help documents, the whole nine yards. This should obviously not happen.
Communication is key. We must let the business know that the prototype we made is not the final solution, and that putting off the cost to them of creating something more permanent will cost more in the longer run, due to the work done around an incomplete prototype to make it fit in and work.
Testing a prototype all the way is not always in the cards. Regardless of how much QA complains, we need to know if we can do a thing. We are removing the fear of if we can, not making a final product.
The bigger picture
If a business ends up with several prototypes in production, due to its need to release features, then this series of incomplete, unstable or untested solutions will create a mesh of difficult to replace and interconnected workarounds and technical debt.
As a business owner, you need to learn to acknowledge that creating a prototype is just that, and that you must assume that all the wires need to be pulled out and the real solution built again with the things you've learned.
MVP fever
It is so easy for a business to see an impressive product demo and make the assumption that this is a complete solution. The technical parts in between, or even the reasons why it is a bad idea to assume this is a minimum viable product sometimes escape product owners and project managers. It is your job as an engineer to help them to understand the cost they will incur in the future if they do not heed this warning.
It's very common for a full test suite to be missing from a prototype, since testing is not always part of making sure that something is technically possible. This should be part of your technical debt log. If it's testable, test it. The final solution must be tested properly.
This of course has it's own problems. If you omit full testing because your prototype is to prove a point, and the business takes it as a product because it got carried away with the stakeholders, then it will be missing the full suite it needs in production. This is dangerous and happens a lot, so watch out for it.
Benefits
Learning new skills
Doing a prototype to see if we can, forces people to step into unknown territory, and you may find that either you or your team needs to take on a technology you've not used before.
Sometimes, it's even an experiment in a totally new technology. This is absolutely essential for a business to thrive. It is for this reason that I consider prototyping to be one of the most enriching experiences for engineers.
We may also learn new ways to work as a team, and I can assure you, you will learn new skills that you did not know your engineers had. You will find skills they have in tools you had not considered.
Make notes of the things you need for Toolsday.
Becoming braver
We will become more brave. Learning that a thing is possible makes us more confident that the product we will make with the learning we took from our experiment will be the best we can build.
We will make stakeholders more confident and we will be on the right track technologically. It is a win-win for everybody involved.
Apart from the person who pays the salaries. There is a risk that we wont learn everything we need, or that, we are wasting our time and we should dive into making a different solution.
We have to get brave here too. We may fail and we may make poor decisions about replacing the prototype before launch. We have to be stronger here if your leaders think this way.
Teamwork
It's dangerous for a prototype to be made by a single person, even though from the perspective of the company, it seems like a sound strategy. Take a single person and get them to take a risk for the business. If it fails then you're only losing one person's time and this seems like a more acceptable loss.
This needs to be a team effort. If parts of this solution or ideas from it become a new system, or the lone designer of the prototype leaves or is re-assigned then there is a risk that we will have learned nothing from the prototype phase.
Mob it as a team and learn as much as possible.
Seeing the future
Although a prototype should prove we can do something in a reasonable time for the business, we should also bear in mind the future and what it holds for the correct solution, and how that might be used in the business.
Plan the final solution and make sure this is part of the prototype too.
This sounds backwards, but think of this example:
If we make a system that adds two numbers but we ignore the fact that we will be calling it with a REST API, then we are missing the point. We need to make a REST API that adds two numbers.
Don't ignore the simple requirements of the final product in your prototype.
Key Takeaways
Prototyping is about mitigating risk
You may think you already know the best way to do something because this is how you have always done it. You are very wrong. There are all sorts of better ways to solve problems.
The distance you have between the ideal solution and your prototype is your technical debt. Always plan to close this gap, as soon as you can.
Don't let a lone hero do a prototype. Work on it together, you all need to learn how it was solved.
The thing you make is not forever, it only exists so you can prove its possible. The longer you hold onto the prototype, the more expensive it will be for the company in the long run.
Whatever you do, do not ever put the prototype into production, its not good enough, it never is.
Get brave and try wild ideas. Nobody ever wrote amazing solutions playing it safe. Nobody.
Can you turn this into something production worthy later? Keep your eyes on the prize. Don't do things that trap you in the corner technologically or operationally.
Top comments (0)