Making IoT projects real turns out to be hard. Really, really hard.

Sure, all worthwhile product development takes time to perfect. But, as software developer Alan Cohen argues, the 80/20 rule for standard product development turns into 95/5 for IoT projects. That is, the first 95% of an IoT project takes 5% of the total development time.

For those keeping track at home, this means that 95% of your IoT development time will be spent on that last 5%.

This means that developers jumping into IoT need to keep in mind that “magical products aren’t easy to make,” and budget their time accordingly.

Tempering unrealistic expectations

One of the first problems confronting any IoT developer is the industry’s distinct lack of standards. In a report, McKinsey & Co. notes that “Interoperability between IoT systems is critical,” but goes on to lament the mishmash of conflicting “standards” that plague IoT’s market potential.

As I’ve suggested, though vendors dominate the more than 400 competing standards, the battle for developer hearts is more likely going to be won by de facto open source standards.

Even so, the problems with IoT development don’t end there. More unfortunate still, IoT development can appear deceptively simple, as Cohen stresses:

[T]here’s a ton of effort needed to go from ‘in the ballpark’ to ‘what we actually want to do.’ But when it comes to the Internet of Things, it’s both particularly easy to get something magical working a little bit, and particularly difficult to get the thing completed. When developing IoT products, this giant gap can lead to unrealistic expectations about project scope in the early phases.

It turns out, he continues, that there’s a huge delta between “proof of concept” and “runs in production”: “IoT’s tendency to incorporate sophisticated technologies that can be devilishly tricky to make reliable and to do just what we want in real-world uses.”

But, again, it wouldn’t be so much of a problem if IoT didn’t tease us with simple beginnings.

Looks can be deceiving

Take wireless, for example. For less than the price of a movie in Manhattan, a developer can purchase a kit that comes with Wi-Fi and a microcontroller. Just two hours later, “It’s talking on the Internet via a local Wi-Fi access point, and you’re reading Web pages and sending text messages.”

But before you file for an IPO, Cohen warns, this deceptively simple wireless beginning quickly runs into a roadblock. Actually, several:

  • Without a keyboard and a screen, how will you tell your IoT device the passcode for accessing the Wi-Fi? With enough code and time, of course, it’s possible, but that significant effort isn’t obvious when you’re first snapping together a proof of concept.
  • Things like RF errors are common, yet it’s not trivial to ensure they don’t render your IoT device inoperable. Planning for these sorts of likely hurdles becomes critical.
  • Speaking of RF, it will require FCC certification. If you think “government” and “easy” go together, well, you haven’t been working in communications very long.

Nor does the fun stop with wireless.

As Cohen points out, things like sensors (“most still have analog sensors at their hearts, which means we have to be very thoughtful about things like tolerance, drift, and temperature constants that are usually not interesting issues with purely digital systems”), power (small batteries coupled with “RF transmission and reception, which can each draw a good slug of energy”), cloud services (maintaining control, ensuring scale, etc.), and more combine to make IoT development exceptionally difficult.

This isn’t meant to dissuade developers from trying. After all, McKinsey forecasts $11 trillion in economic value from IoT over the next few years.

Even so, no one should assume IoT product development will be easy, even if hacking together a proof of concept is.