It takes tools to streamline IoT development into survival
April 13, 2017
1,109 companies at CES this year called themselves “smart home” companies. 882 companies took the “wearables” label. Hundreds of devices came out of these companies, many as hopeful as a certain...
1,109 companies at CES this year called themselves “smart home” companies. 882 companies took the “wearables” label. Hundreds of devices came out of these companies, many as hopeful as a certain popular smartwatch company was when they raised their first (of what would be three) multi-million dollar rounds of funding.
80 percent of these devices will end up the same way – gone.
My choice of this smartwatch company as an example wasn’t arbitrary. From the outside, it appeared they did everything right: they had a beloved product, strong marketing, and millions of devices sold to happy customers. But the thing was just too expensive to make and keep afloat. If each watch they sold made money at all, it wasn’t much.
Making a smart device is hard, which means it takes lots of expensive talent. It’s also slow, which means more months of writing checks to said talent. At the heart of it all is complexity. Besides the usual challenges of hardware, the Internet of Things (IoT) is further complicated by factors like the nascent market, limitations inherent to low-power environments, and the need to manage (secure) connections to the cloud, smartphones, and/or other devices.
It’s possible to scale a mountain without the right tools, but you’ll probably just die. Developing an IoT or otherwise smart device is much the same. Complexity is the single greatest threat to a device manufacturer. Therefore, the most pivotal moment for such a company is figuring out how to manage that complexity. That means tools — and just like a climber, the only tools you’ll have available are the ones you packed while still on the ground.
By tools, I’m not talking a good integrated development environment (IDE) and some kind of scrum software. I mean the ones that mitigate the serious setbacks and bottlenecks likely to arise from complexity. Let’s review some.
Bottlenecks of embedded development
First, embedded development, which is any kind of development for a device other than a dedicated computer like a desktop or phone, usually means using a lower level language like C. But by that example, there are only 500,000 qualified C programmers in the world, while others like the Java language sport communities of well over 10 million. A good virtualization tool can vastly widen your potential talent pool, giving a solid return on investment (ROI) from day one.
Next, the hardware market is very fragmented when you’re talking embedded. There’s something like 50,000 different microcontrollers and microprocessors alone, and that’s before you consider different kinds of memory, sensors, peripherals, and other components. Figuring out the ideal combination takes time, and most software development can’t usually take place until it’s done. But prototype boards and their accompanying toolkits let hardware developers iterate quickly and hone in on options without days of waiting for their hardware orders to arrive.
Connectivity, which is core to IoT, makes security paramount. We saw the potential consequences of insecure devices with the recent Mirai botnet, where malware on connected devices comprised a large part of the distributed denial of service (DDoS) attack that brought down a major domain name server (DNS) provider. While plenty of security solutions exist, none of them provide a magic bubble you can simply wrap around your device when it’s done. You need to choose your solutions early and design with them in mind.
Then there’s the lag time between hardware development and software development. Embedded software must be written specific to the hardware, meaning there’s little software developers can do while they wait for hardware to finish. Worse yet, if the hardware team decides to make a change, software must go back and change lots of old code.
But certain hardware-agnostic software platforms can let software developers start before hardware is finalized, and even debug it via PC-based simulators. This is especially important given that it takes roughly two months to print an alpha board after a hardware design is finalized; such a tool means developers can do more with that time than twiddle their thumbs.
The dependence software developers have on hardware reflects the more general problem of not being agile. When software developers can’t commit code before they understand the hardware, and when hardware knows that a single change can set back the software team by weeks, deviating at all from the original plan is risky business. By using tools that soften this dependence, teams can not only make unplanned changes as necessary but also work in parallel, which alone cuts months off development time.
In IoT, agile development isn’t just good practice, but necessary to making a competitive product. The industry is changing at such a pace that a great fit for the market in January could be a flop in June. An agile team that has mitigated complexity won’t fall apart when the marketing team calls to say they need a new feature. With all the competition out there (recall the 1,109 smart devices and 882 wearables) this is more of a “when” scenario than an “if” one.
Tooling your development lifecycle
This all sounds daunting. To an extent, it should. But development, especially in software, has always been about anticipating problems as early as possible. Just as you write your architecture before you actually code, preparing yourself with tools and plans to handle complexity is simply how you start making an IoT product.
What’s better, these tools are already available and, for the most part, affordable. Prototype boards cost a fraction of the average workstation and pay for themselves many times over. And virtualization tools, while fairly new to IoT, already solve much of this complexity as soon as they’re implemented.
Complexity in IoT development will get easier as the years go, as the industry finds its best practices, and a handful of platforms become mainstream. Mobile development faced the same growing pains, and for many of the same reasons, but now nobody questions whether or not smartphones are profitable. With the right tools in hand, reaching that same summit will be no trouble for IoT.