Collaborator8.2-Blog-CTA-Demo

Get Smart: Careful Code Review and the Internet of Things

Internet of Things - Development

Illustration by Heather Scoggins

Are you prepared for the ? A world in which virtually all devices, from your shoes to your refrigerator, will be connected to the net and transmitting data, 24/7? If you’re a developer, you’d best be ready, because the IoT train shows no signs of slowing down—and the route ahead is anything but clear.

Whether you’re used to programming iOS apps, MMORPG games, e-commerce websites, or corporate databases; whether you enjoy coding payment gateways or spend your days ensuring that the latest Android phone’s GPS is playing nicely with your new health-tracking wristband; the fact is, there is almost no conceivable variety of programming experience that will remain untouched by the IoT revolution in the coming months and years. Smart watches will want to talk with smart clothing. Smart cars will want to talk with other smart cars. Smart blenders will touch base with your dieting app, refusing to let you make another chocolate milkshake if your caloric intake for the day is over the line. And every device and program is going to want to talk with your smart phone.

If you’re a developer in pretty much any field, it’s time to get creative. But if you’re someone who works regularly with APIs, may the digital gods have mercy on your soul.

Your world of smooth-talking software is about to get complicated.

Married Devices and Communication Issues

If you’ve ever spent way too much time trying to get an ordinary Apache server to communicate with an ordinary MySQL database properly, battling through port conflicts that shouldn’t exist, then you know that even in the best of circumstances the internet can be an unruly beast. Never mind any number of API issues that keep programmers continually scratching their heads. Now, plot a few years of frustration on a rapidly ascending exponential curve, and you may be able to appreciate why, despite its tremendous promise, the IoT revolution is going to take a little while to fully manifest. When we have so many devices that are potentially capable of talking with each other, we’re just asking for communication trouble. And a failure to communicate is the main obstacle in the path of an IoT future.

Some enterprising startups are starting to take a crack at the problem with simple Event-Condition-Action controllers, such as WigWag, an Austin, Texas-based project that recently hit its Kickstarter goal (and then exceeded it by a cool $400k). WigWag consists of a smartphone app that communicates with proprietary sensors placed around the house, which detect environmental changes—such as the opening of a closet door, a bedroom light being left on, or someone snooping around your back porch at night—and then perform easily programmed actions, like sending you a text notification, turning off the light, or sounding an alarm. Its main selling point lies in its diverse functionality and ease of use, with a nicely designed user interface and if/then commands that even the least tech-savvy iPhone user can program. “WigWag,” says its founders, “is about making intelligent decisions—to make automated environments convenient, not annoying.” What seems most significant, however, is WigWag’s ability to communicate with third-party components, such as Belkin WeMo electrical outlets and Philips Hue light bulbs. And it aims to expand its circle of inclusion by communicating through one of the most common languages of all: Javascript. As the developers explain:

DeviceJS is an open-source runtime for executing Javascript. It is built on Google V8 and Node.js. Anyone who knows anything about programming should be able to start hacking things in the physical world easily. WigWag uses the same language and many of the same programming patterns that drive millions of web pages today.

As an affordable and well-designed way for consumers to finally enter the smarthome era, WigWag may be in a class of its own. But even if multipurpose devices like this, running on a universal standard like Javascript, begin to resolve some of the communication issues posed by an emerging panoply of smart devices, we’ve only won half the battle. The other half is making sure that the very basis of communication itself—i.e., code—actually makes sense to begin with.

Squashing Bugs in Autonomous Cars

Consider a simple equation:

A + B = X

Where A = Apple Maps, B = a self-driving Google Car, and X = a trip to the emergency room.

Yes, Apple Maps has steadily improved over time, but its disastrous initial deployment deserves at least a few more years of jokes, and the point should be clear. If you couple autonomous, “smart” hardware with glitchy software, you’re asking for a world of hurt. Of course, if the smart device in question is just a light bulb that should turn on when you enter the hallway at night, badly written code might only result in a stubbed toe. But if it’s a smart oven, smoke alarm, or fire sprinkler system we’re talking about, human lives may be on the line. Ordinary app developers could suddenly find themselves needing to take the same precautions, and engaging in the same degree of testing and code review, that software engineers for airline autopilot systems (and their insurers) already require.

Moreover, with smart cars or smart medical monitors, one glitch in the Matrix can obviously result in serious problems, but potential disaster lurks around every corner in the IoT world, no matter how innocent any particular smart device may seem. Why? Because the whole point of the IoT vision is that all those individual devices are connected, networked, like the countless sites that currently comprise the web. One bad link can lead to a systemic failure, as the smooth interactions between devices start to become more important than the functioning of the individual devices themselves.

The Google Car, again, offers an easy example. With autonomous vehicles ruling the road, one of the biggest benefits will be found in the ability of cars to form tightly knit highway caravans, driving closely together in packs that reduce the drag coefficient on individual vehicles by creating slipstreams, just like professional cyclists’ drafting techniques. Intelligent automobiles driving more closely together—and reacting more quickly—than human drivers can handle will undoubtedly save time, fuel, and greatly increase traffic efficiency. But what if just one of the cars in a massive commuter caravan has buggy traffic-sensing software installed? Perhaps the neighboring cars’ rapid reflexes would navigate it successfully, but if not, then the resulting pileup could be disastrous, making its hapless participants yearn for the days of mere four-car collisions

Clearly, in an IoT world, clean, carefully written code, proper code review, and repeat testing are going to be more vitally important than ever before.

Warning: Continuous Deployment Required

If we continue with the example of smart cars, the need for smart infrastructure soon becomes apparent as well, so that traffic lights and vehicles will be speaking the same language (some even suggest the need for smart pavement too). What’s also obvious is the necessity of either standardized, universally regulated software or robust and adaptive APIs, to avoid having too many upstart traffic-nav programs trying to outperform each other when they should be communicating nicely instead. After all, given the large-scale physical devices involved—from cars to appliances—creative competition and innovation may often need to take a backseat to safety standards and legal regulations in the IoT world.

Yet even if every car on the road is running Google Nav software, it won’t really work if users are permitted to update their software manually, inevitably resulting in bugs and outmoded software remaining on the road for years after fixes have been released (IE6, anyone?). No, updates will need to be pushed, perhaps multiple times a day, to all users at once in order to ensure that programming errors are eliminated as soon as they’re spotted and that this literal “information superhighway” keeps traffic running smoothly and safely. Software monitoring will be critical as continuous deployment—and the tremendous benefits it offers for instant rollbacks and daily, incremental improvements—becomes business-as-usual for the Internet of Things.

Based just on these examples alone, it’s clear that the IoT revolution poses no shortage of challenges. But to paraphrase Stewart Brand, it’s already here, so we might as well get good at it. And most importantly for developers and end users alike, it’s undoubtedly going to be a whole lot of fun.

See also:

file-52261875

subscribe-2

Comments

  1. Good article…if a bit scary. As a developer who is still a little stunned that Y2K wasn’t a bigger deal than it turned out to be, I definitely agree that we’re in for some very challenging times ahead.

  2. Thanks for sharing your great post! Awesome! You did a great work, and it is always super helpful to see a internet of things development ideas and look of how something is created.

Speak Your Mind

*