Agile development has been the norm across web and backend development for the last few years. No web developer could withstand the idea of deploy and forget, and no user would withstand a stale website.
The benefits of agile development are well understood, faster iterations mean better quality of service for end users, security, and a continuous flow of new features and services. It also means a very different speed of product development for product owners with the ability to continuously test new features and the interest thereof.
Contrasting this world with the world of IoT and embedded development is night and day. Embedded is full of these deploy and forget devices whose code is never updated. Things are evolving; however, as players like Tesla are shaking the automotive space by packing their cars with electronics that get enabled via software upgrade a few months down the line! As things get connected they need to move at the same agile speed as the web in order to fix bugs, security issues, add new software features or enable new hardware functionalities.
Mobile was a step in the right direction with the application iterating at the speed of agile and users getting used to (or rather demanding) regular applications updates. However, below the applications, things are still moving at a slow pace with a number of smartphones never seeing a new OS release. But, the wider public has gotten used (hooked) to the notion of updates and all the benefits associated with it, and it’s questionable if other consumer devices will be able to survive in the market with these regular updates.
As a wider question, can the IoT and embedded world continue to move at the non-agile pace? Can it actually afford not to? The story of ASUS, who were fined this year by the FTC for not updating their routers, highlights the fact that regulators are looking closely at the Internet of old things and telling the industry to start adopting a new agile approach to deploying embedded software.
What needs to change for embedded to move at the speed of agile?
The number one reason mentioned for embedded development not to move at the speed of agile is the difficulty of upgrading remote devices in a failsafe manner. The IoT industry is full of these stories about failed updates and the subsequent emergency visits to one or thousands of sites. Solving this problem and allowing any piece of software running on an embedded device to be upgraded remotely with automated rollback if anything goes wrong is the first brick of agile embedded.
The second brick of agile embedded has to be the ability to distribute software, as there is little point in being able to upgrade safely if there is nothing to upgrade to. By making a white label app store infrastructure available, it is now possible to quickly deploy software across a multitude of devices with reliability and scalability.
The third brick of agile embedded is the decoupling of responsibilities for the various software layers. A common scenario is that device drivers originate from the hardware vendors, the OS from an OS vendor and the application by the device manufacturer themselves. It then takes a device vendor to take all this software layers and merge it into one software image. If a bug is discovered at any layer the whole image would typically need to be regenerated. A key element of embedded agility is the possibility to update any of the software layers without affecting the others.
Without this approach, the IoT developers will struggle to unlock its true potential. An agile approach will not only protect business from security issues and litigation, but also deliver new opportunities to businesses and users alike. And the beauty of it: The agile approach is well understood and we can learn from those who laid the foundations. We don’t need to reinvent the wheel, just use it in interesting ways.
