June 15, 2017
Our CTO Martin Unger gave a presentation at AWS Summit on how we conduct rapid prototyping and what we’ve learnt from doing it. Here’s the recap.
Let’s start from the beginning. WATTx is a venture builder creating deep technologies for consumer and industrial applications. Our full-stack team performs research, generates ideas, validates and then prototypes a solution before making a new venture a reality.
Since we want to make this process as robust and efficient as possible, we’re going to dive into our prototyping process and how rapid prototyping in IoT comes with different demands and challenges in comparison to more classic product development.
We develop prototypes because we want to test our idea with real users as quickly as possible. After all, they are the ones that will ultimately use the solutions we’ve built. We do that by collecting their feedback on our current prototype and iterate on the solution based on the feedback we got. That way, we ensure that we build a product that our users want, instead of a product that we think our users want.
Here is a rundown of our six keyrequirements for a successful prototype.
A prototype doesn’t need to have all the functionality planned for the final product. However, the core functionality need to be there and it needs to work. By developing a fully functional core we get more valuable feedback from our test users, insight into possible pitfalls and time sinkholes for product development, and we’ll have something to show interested investors.
We need a prototype to be stable - as realistic tests, in most cases, take time. We also need to collect data in a consistent, continuous manner as well as enable substantial measurements to feed analytics and machine learning.
On one hand, we need monitoring to know exactly what is going on with our systems. Is a system down? Has our newly added function started to spam test users with notifications? Those things are, of course, essential for us to know about.
We also want to know how users interact with what we built. Interviewing users is great for gathering subjective feedback; however, when it comes to logging and monitoring data, you need an objective way to validate what they say by looking at how they interact with the system.
While prototyping, you want to be able to adapt to changing requirements quickly. You should also be able to add new ideas or try different approaches as easily as possible. To support flexibility, for example, we use Swagger as API-framework and separate small services that do most of the heavy lifting. Thus, different parts of the system can be largely implemented independently using different tech stacks or already existing services.
As mentioned, when we prototype, we are constantly learning about potential pitfalls, new approaches, and useful toolsets. By developing a good understanding of those, we can develop a clear roadmap for building a kick-ass MVP.
We are full believers in lean prototyping. In many cases, a lack of resources will incentivise to think outside the box, beyond the most obvious or complex solution, take shortcuts wherever possible.
However, there’s also many services out there that can help you with reducing development time and complexity. This choice, weighing time and resources, is left to our developers.
Building a prototype is not the same as developing a full-fledged product. To illustrate that point, have a look at the following two examples below:
What would you say is good code when prototyping, the example on the right or on the left?
The example on the left does the job. The example on the right is more maintainable and presumably the better fit for a production setup where different people have to work with the same codebase over a longer timespan.
However, we don’t want maintainable code. Maintainability is unnecessary if not even counterproductive in prototyping!
We believe that if developers put too much care into their code, they lose speed and focus. They also tend to get attached to their code and this is not what we want.
We want them to throw away their code, and do complete rewrites on each iteration, as we move forward. Our reasoning is that we don’t want to put boundaries on the possibilities of how to tackle a problem by adapting an existing codebase instead of starting from scratch, in green fields. There are fundamental changes happening from one iteration to the next in the tools we use as well as the architecture and the functionality of our prototypes.
To sum it up: old code goes into the trash can, but what we learned from that code stays with us.
An infrastructure tailored to the specific needs of prototyping is essential for saving you time. And our infrastructure is very different in comparison to what you would see in a company that works on maintaining and developing in production.
When working in production, you’ll probably need the following from your infrastructure:
In prototyping, we need infrastructure that is:
Bottom line: A good prototyping infrastructure allows you to start and stop quickly, and makes sure that you can focus on developing without having to create new infrastructure for every project.
When developing for production, you need someone that focus on maintainability, testing, and documentation. In many cases, you want your developer to have expert knowledge with a specific toolset or framework, like Elasticsearch or Spring. And maybe you are looking for perfectionists. Developers that turn their noses up to shortcuts and quick hacks.
However, to be a good prototype developer, we believe that you need a very different skill-set.
If we try to boil it down to a sentence, we are looking for developers that are first and foremost entrepreneurial explorers and team-players.
By setting clear requirements for what a good prototype is, and employing the right people and infrastructure to build any sort of prototype, you maximize your chances for success. We believe that if you have those three things nailed down, you have the core ingredients that you need to do rapid prototyping for IoT.
WE ARE WATTX
A recap from our last internal hackathon. We used AR to visualize sensor data, created...
WE ARE WATTX
This is the fourth part in our article series “We are WATTx” in which we...
WE ARE WATTX
Since summer, WATTx is now led by a tandem of Martin’s with our new COO...