AWS Recap - Rapid prototyping in the Internet of Things-realm



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.

Why we build prototypes and what we require from them

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 successful prototype needs…

…a fully functional core

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.

…to be (somewhat) stable

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.

…to be fully monitored

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.

…to be easily adaptable and extendable

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.

…to provide a stable ground for building a MVP

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.

…to use as little time and resources as possible

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.

Developing a prototype

let your developers build on green fields

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.

Prototyping demands a different type of infrastructure

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:

  • It needs to be cost efficient - you want to keep costs down.
  • Close to 100% availability.
  • You need it to be well-documented and designed.
  • It needs to be secure - you need to continually test and review your infrastructure security.
  • Administrators or Ops are essential - experts should take care of the fundamentals.

In prototyping, we need infrastructure that is:

  • Easy to setup and use - everyone should be able to setup an environment quickly and without fuss.
  • Out-of-the-box functionality - we want different storage possibilities and computing platforms from day one.
  • Flexible scalability - we don’t want to manually scale up or scale down a prototype, that should be taken care of automatically.
  • Included monitoring and alarming - it takes ages to set up, and is extremely valuable, so it’s a core part of a functioning infrastructure.
  • Pay-per-use service offering - We don’t want to lock ourselves into long-term contracts or monthly fees when prototyping.
  • Global and regional availability - We want to be able to run services regionally or in a specific country as, especially in Europe, there is a lot of different legal regulations that you need to consider. You also want to offer the best possible performance to your prototype users.

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.

Prototyping also requires different skillsets from developers

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.

  • First of all, you need great social skills. You will work with a mix of personalities and need to stay flexible in order to make quick decisions together with the team.
  • You also need to have a problem-solving mindset. For prototyping, being pragmatic always trumps being a perfectionist. You need to be flexible because you’ll have a range of tasks during every workday.
  • We also value a broad knowledge-base over expert knowledge in one or two subjects, as we are always working on new projects that require different tools. It’s essential that team members bring natural curiosity, an ability to learn quickly, and willingness to by getting their hands dirty from day one.
  • And a developer that loves to work with APIs allows us to develop prototypes with interconnectivity instead of monoliths and to make use of existing services wherever it makes sense.
  • Finally, we look for an entrepreneurial mindset. Team members must act independently and take responsibility not only for their own work, but also for their project and for the development of WATTx at large.

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.

Wrapping it up

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.