Recently I was involved in creating a prototype for a product. Since it is a different process from production work, I thought I write up my thoughts on prototyping.
How is it different?
When you code for production the goal is for your code to be as clean and well thought through as possible. It needs to be proven to work in the defined constraints. It should be authored in a way that the rest of the team should be able to pick up your work and run with it. Before starting any implementation you need to formulate a plan and make sure the new code, or the change, fits in with the overall architecture well.
Prototyping, on the other hand, is somewhat different. In my mind, the goal of a prototype is to prove an idea with the minimum amount of effort possible. You should learn from the prototype and use that knowledge to make informed decisions.
When to prototype?
From this, the criteria of prototyping can de be defined as the following. You should only start a prototype when you have unanswered questions and no known way of solving them. The process tends to be exploratory and the code, art, design you produce can change drastically between various steps and check-ins. Make sure you are clear about the goal of the prototype and the time allowed for it. If either is not defined you may end up having a total feature creep to deal with.
Coding when prototyping
Prototypes are explorations towards an idea or a problem. Therefore by nature, they need to be completed in the shortest time frame possible. To that end, coders may prefer to use methods that are less overall-architecture friendly. They may also decide to reduce the clutter that may impact delivery such as not commenting, documenting and skipping test-writing.
Managing the process.
Make sure you know who the stakeholders are before starting. They should be involved in daily meetings, planned and ad-hoc discussions. Once the code works, even at stages, show and tells should be organised. It also helps if there are interim review builds made. Stakeholders will then need to provide feedback. Afterwards, the team should make decisions about changing the scope and dealing with the fallout of that.
Should the code end up in the production codebase?
In an ideal world, the code produced should not end up in the production codebase. In reality, it always happens. Relaxing coding and architecture rules can be dangerous. After a successful prototype, the programmer should update the code to fit in with the overall architecture, documentation and testing rules. If this is skipped the codebase and maintainability of it will suffer.
Summary
For us, prototyping is a great tool. It can help to find solutions to problems and answers to questions we don’t know upfront. You can use to quickly try product ideas too. It needs to be managed just like any other process. If successful make sure to get any code over to production carefully.
If you have any comments, ideas or personal experiences, feel free to share with us. We are curious to hear new ideas, solutions, and perspectives regarding the above. Don’t forget to follow us on our social media!
You can also find the rest of our blog here!
