Things that I have learnt at IoT projects as software developer
As software devs, commonly we are used to writing code in an iterative and incremental way. This usually leads us to choose an agile methodology for software development.
As Brooks exposed in his popular No Silver Bullet paper, software is complex, conform, invisible and changeable. Then, a challenge arises, not only at development but also at project management, while treating with components that are not very malleable or are severely influenced by the physical conditions where the application is running. These scenarios may arise at IoT projects.
Before continuing, I’ll introduce myself, I’m a React Native developer at Wolox and recently worked at two IoT projects — one involving a camera to record amateur football matches and trim them via an app, and another involving a Bluetooth toothbrush which record users’ sessions and let them earn points by each minute spent brushing their teeth.
How do we start?
The football project had a very recommendable first step, that help us to figure out if the project is doable or not. Although this step seems to be a bit obvious, is it worth to mention that in in this step we need to elicitate those requirements that will be hard constraints for us — those that will be related to the hardware itself (e.g. power consumption, environmental characteristics, data processing & storage, size…) and limits the use of the hardware.
Once we have the goal and our hard constraints for our project, we need to define devices in order to start making a prototype (this may be an Arduino or a Raspberry Pi, by example). We need to make sure that those hard constraints will be respected at every moment while developing our prototype so testing will become handy at this point. With this device definition, we’d like to also define which sensors and microchips will come to play at the hardware party, and the software infrastructure (e.g. storage, cloud processing) needed to put them to work.
On the other hand, projects like the Bluetooth brush one had the device predefined, so defining a device to make a prototype in these cases doesn’t make too much sense. In this case, it is preferable to deeply know how the device itself behaves at the very beginning of the project. (By example, we knew that we can enable/disable Bluetooth from our brushes at nearly the end of our project. Lack of this knowledge led us to put more effort debugging and figuring out why our brushes stop responding).
In either case, we need to find these hard constraints, the earlier, the better. Keeping in mind these constraints will make software development a bit more kind. Moreover, since the hardware is clearly less malleable than software, we need to know all requirements that are related to hardware — expected behavior, constraints, environment, and so on.
This knowledge might come up with a question: should we need an iterative, incremental process for our project? In my opinion and experience, this is not needed for hardware but it’s essential for software. This may be accomplished by separating software and hardware development, since by nature they have different development velocities — developing, debugging and testing hardware takes much more effort than developing software, since this process is affected by other factors as power supply, environment conditions (temperature, humidity…) and even unexpected interactions (such as interferences).
Remember, avoid using an iterative methodology unless we can ensure cheap iteration costs.
Know how to communicate with the prototype
A thing that in my opinion becomes critical at IoT projects, is the need to communicate with our prototypes at the time our software evolves. In order to start designing an architecture, we’d like to answer some of the following questions:
- Which will be the main communication channel? (WiFi, 4G, Bluetooth…?)
Although WiFi and 4G may be quite similar, they differ depending on our scenario. One key difference is the infrastructure needed to support one or another. For example, for our football IoT project, each camera have their own 4G module in order to adapt them to many pitches.
- How many interactions will have our prototype?
- How often our prototype is interacting?
- Which protocol will be needed to communicate with them?
In some cases, communication problem with our prototypes may be already solved with a third party SDK which manages all our low-level stuff (this was the case of our brushes project).
In other cases, since we need to ensure that we can develop a Walking Skeleton at an early stage, it’s a common practice to do Smoke Test so we can validate our channels quickly. For example, we encountered that our ISP blocked nearly all TCP requests to our Raspberries, so at our Football project, we ended up using an AMQP protocol.
These will bring an idea of how likely is to fake the IoT prototype. This is very important and often, we’d like to mock our prototype at a software level, since hardware and software have different development velocities.
If possible, avoid processes that hold hardware too frequently — like directly develop with the device. Hardware, as opposite of software, is a limited resource; this means is more difficult to share these resources with other members of our team. A possible scenario is that devs and QA need the same prototype to test things as well. If we don’t have a plan to proceed here, the prototype itself will likely become a bottleneck for our project.
Conclusion
Hardware has a different development velocity than software, and develop a prototype clearly requires much effort and knowledge. But by integrating hardware to UX, a world of possibilities will open.
IoT projects aren’t only entirely about how we deal with hardware, but also how we deal with collected data. IMHO that’s the heart of every IoT project.
