The (mainstream, information) software industry thrives on standardization and scale. For servers and desktops, Intel’s x86 architecture has become the universal foundation, the UNIX userland model (and Windows) reign on the server, the PC desktop/notebook space is overwhelmingly dominated by Windows and OSX, tablets and mobile phones are similarly split between Android and iOS. The software industry likes some level of platform competition, but things tend to shake down to two major choices, and sometimes we end up with quasi monopolies.
There’s obviously endless variety of apps and services on top of those foundations, but the software industry really loves monoculture when it comes to platforms. Platform wars in the industry, like the “Windows vs. Linux” evergreen, or “Android vs. iOS” are driven by that desire for monoculture. Software is a complex world, and most people in the industry have little choice but to invest deeply in a particular slice of that world in terms of learning and experience so that they can stay competitive. If their chosen slice of the world doesn’t end up becoming everyone’s favorite monoculture it threatens people’s carreers. People make bets on the future and then try hard to make “their team” win. The people in software love one winning platform - “theirs”.
Monoculture (and “duoculture”) is great for scale. If you’re building a mobile phone app, you build for Android and iOS. If you’re building a desktop application you build for Windows and OSX. Or sometimes you start just with the bigger target or the target that’s most used by your target audience. Any of those platform has hundreds of millions of end-users to try your product on.
One of the most interesting aspects of the “Internet of Things” (IoT) wave is that it represents the software industry’s attempt to make sense out of the diversity of “Things”; a diversity that is entirely alien in the mainstream software industry. “Things” is a giant and impossible technology umbrella. Under the term “IoT”, the software industry discusses adding digital capabilities to “Things” that span anything between a super tanker ship to a throwaway digital label sticker on a cereal box. And it’s often outright amusing when the software industry treats “Things” as if their approach to making hardware was novel in itself and that the true complexity of building “Things” were not existing.
Another difference that software people struggle with, sometimes with outrage about the perceived unfairness of it all, is that the barriers to enter any market requiring manufactured products are significantly higher than in software; you’ll always need a lot more than a notebook, a coffee shop to camp in, and some base funding for cloud compute and storage resources.
Creating tangible “Things” requires broad mix of engineering talents, there’s a supply chain to manage, and there are often complex sets of (internationally diverging) safety and other standards regulations to comply with. And because most industries don’t favor monoculture and one king for every hill as much as software, there will always be competing vendors that will aim to play the profit margins game better, and therefore it makes a real difference whether a particular component can be sourced for a few cents more or less per unit and that there is no costly unused capability.
Software’s strategy to deal with heterogeneity is standardization; and therefore the mainstream computer/software industry comes up with platform: There are dozens of different tiny computers (“maker boards”) that each provide enough ecosystem scale for someone to invest their time in. Arduino/Genuino has a thriving community, because it provides a family of boards with a matching set of easy-to-use tools that work equally well across that family. Most of those tiny computers have a common way to speak to external components like attached servos and sensors. And those tiny computers are easily networkable, and their software platform has ways to easily integrate with other software on server computers or in the cloud. It’s software’s take on hardware.
That sort of standardization is, so far, not hardware’s take on hardware; especially not at consumer product scale. Very many if not most toys you can buy in a toy store today have some electronics; nearly every kitchen appliance, big or small, contains electronics; cars are rolling miniature “data centers” with several dozen microcontrollers and processors. Quasi any of these digital components has a custom design that is made of the exact components required to fulfill a predetermined set of tasks, even if those can be enhanced and varied with software. Microcontroller types come in dozens and sometimes hundreds of different variations that satisfy a basic demand for some level of platform commonality, but nevertheless differ in available memory, nonvolatile storage, clock speed, power consumption, shielding, physical footprint, and special capability such as on-chip cryptography or signal processing. “Embedded systems developers” have the particular skill to deal with such a diverse capability zoo where devices have very little in common and there is no platform standard.
The maker boards are great prototyping platforms, but at consumer scale they are far from being cost competitive with a custom circuit board and specially selected and sourced components. It might not be so terrible if that cost could be offset by vastly broader, software-based functionality in a product, but how many devices in addition to the general-purpose phones and tablets do we need where software plays center stage?
There’s a different kind of standardization that is common in everyday hardware and that’s centered around user interaction. A hammer is a hammer. In products where a basic function is well known and doesn’t require “smarts”, electronics best enhance the capability; it quickly tips over to the silly if they attempt to take center stage.
There are a few and (mostly) intuitive variations for how to control a water faucet in a washroom; the electronically controlled, sensor-operated faucet has become the modern default choice for public spaces. Sensor-operation has several clear benefits, requires no cerenomy to operate, and the function doesn’t get in the way of the design. It’s a perfect enhancement.
Software’s leaning towards monoculture sadly reflects in interaction design and how that spills into IoT devices. Today, software generally surfaces to people through some form of a pixel grid display, and it allows interaction via keyboard, touch, stylus, or some pointing device - because that’s how the standard, general-purpose consumer information and communication devices interface with people. That interface model is not necessarily the best way to use functions of a special-purpose tool or machine. Without having such obvious prior art to look at, the most common “IoT” software solution for turning on a faucet might just be to put a touch screen display next to it or, worse, require the user to use a smartphone app.
Software wants to play and retain center stage. The hipster “IoT” door bell (or door lock; there are now plenty to choose from) comes with an app and the maker really wants you to think of it as thing you care about as an important part of your life. There’s a motion sensor, a camera, two-way calling, and an affordable cloud service for just a few dollars a month. You can get push notifications! The app has new features every month. And statistics! But these cookie-cutter, standalone door bell devices are mostly clunky and look awfully out of place on mostly any building, and outside the demo videos, few of their features matter after the first excited week of ownership.
Besides, if you really need two-way calling between your mobile phone and your door bell you could buy available solutions for more than the last two decades, and in a myriad of style options that fits the design and architecture of your house. And you still can. And some of them even have apps now. Because there’s an existing industry that has done building entry systems for a hundred years and they have, amongst other things, also figured out how to construct those things such that you can’t just easily rip them off the wall and walk away with them. And they already do digital keys, smart phone NFC, card readers, and finger-print access control in a modular fashion; they don’t aim to get in the way or take center stage and the manufacturers have well established relationships with architects and firms who install those systems.
For most devices and tools used in our daily lives, we care about the primary function and the form. A spoon needs to be a good spoon. It needs to be comfortable to eat from, comfortable to hold, have an attractive shape, and it must not easily bend out of shape or be susceptible to lasting discolorations.
There are indeed several IoT startups that want to hit it big with “smart” forks and spoons; if those spoons or forks are not primarily excellent spoons and forks and then also some sort of revolutionary diet tracker, nobody except the extreme techno geek fringe will ever care about them. And nobody, nobody! will ever want to battery-charge a spoon.
Excellent water fixtures are difficult to make. Excellent windows are difficult to make. Excellent piping and pressure vessels are difficult to make. Excellent gears and drives are difficult to make. Excellent vehicle suspension systems are difficult to make. Excellent rocket engines are difficult to make. Machines that have moving parts and that need to deal with the reality of physics, reliabily, safely, and sustainably are hard to make. And the market differentiation for these machines is that they do their primary job better than any other machine, which is largely a physical interaction function that may then be aided by supporting software. But software doesn’t take center stage.
As you get to large composite machines like cars and trucks and aircraft, there’s a giant network of multiple tiers of suppliers that form long value chains. Silicon Valley’s favorite auto maker, Tesla, employs dozens of global “Tier 1” suppliers for the various vehicle subsystems outside of what they consider their core competency (in their case, batteries and motors), just like any other car maker.
Much of the integration in these complex machines is already digital. Many car steering wheels are rotation sensors with force feedback that feed into the steering system, potentially corrected by assistance systems like lane-keeping or the electronic stability program. If you feel the steering getting stiffer at high speeds that happens because some software makes that happen. The latest generation vehicles from the leading automakers with radar-assisted cruise control will initiate auto emergency braking and actively refuse to run into an obstacle if it’s physically possible to avoid doing so. The array of airbags around you will pop in milliseconds if a collision is inevitable. All software controlled. All highly specialized systems. Hard real time. Some of those systems have just one feature, and often that feature will never run through the main action sequence during the lifetime of the vehicle. This is software that’s not in the limelight. It’s not “agile”, fairly slow moving, and generally subject to rigorous quality assurance processes because letting an oversight slip may end up killing someone. That software is largely not understood by the hipster quarters of the software world.
“Software is eating the world” is a recent software industry meme and is often used pointing to the ride-share or apartment-sublet brokers that, so far, cleverly manage to push the capital investments to their “associates” and monetize the information channel between those service providers and the customers. Others point to the torrent of home automation and entertainment gadgets brought about by the IoT hype.
The fact is that software already ate a huge chunk of the world, but not necessarily in plain sight. Software on devices often interconnects and orchestrates components, but it’s mostly insular in nature and not wired (or radioed) up to the rest of the world - and in very many cases that is a blessing since software found on devices today had often been written without any expectation that it would ever have to stand up to external security threats.
Some of the “Internet of Things” wave is about the information software industry coming to the realization that this other world exists and it discovers, sometimes in horror, how different that world is. Some of that wave is about pretending that intelligence in devices hasn’t existed until about now and that a coffee maker with a timer function or a thermostat with an outdoor sensor (and a timer function) is somehow novel.
The most interesting tension developing around the IoT will be how to achieve product scalability. There are analyst predictions for tens of billions of new connected devices in the next 5-10 years, far eclipsing the number of mobile phones.
But mobile phones are a class of functionally very similar devices with very similar hardware for which just two competitive operating systems exist, splitting nearly 95% of the market. There’s a driver ecosystem, there are capability profiles, and there is therefore a good foundation for a broad array of common tools and utility libraries to build solutions on.
The overwhelming number of special-purpose devices are custom designed to do a particular set of tricks. There is hardly any standardization and the capabilities as well as the components that provide them will necessarily diverge. Available energy budget, required compute power, available physical space, and required environment robustness, and achievable retail/wholesale pricing force hard constraints for devices where software does not take center stage. In addition, many of the tools from IT land are inadequate. Embedded device programming is often “low level” in order to deal with aforementioned constraints, but also because acceptable compromises in IT, such as a second-long pause for memory garbage collection, are wholly inacceptable for real-time devices.
It’s far from obvious how a investment-happy and rapid-growth industry with the wide profit margins enjoyed by the software industry can emerge out of such a diverse environment.
“IoT” is in large parts about finding middle ground between the monoculture-fueled breadth of platform tooling and capabilities and the wealth of libraries that can grow on top and the need for razor sharp focus for what a device needs. And it’s about software grokking that with physical tools and devices, the are a lot of humble background roles to play in order to make helpful products, and that the key to unlocking useful scenarios is not one device, but a combination of them. We use dozens of tools and devices in the kitchen for a meal, we use dozens of tools to fix the outdoor patio. Each is important for a task, but I’m not going to develop a particularly deep relationship with any one of them. I care about a stocked toolbox more than I care about each tool.
A few cheap and humble functions implemented in a common fashion across many devices may quite well enable great higher order scenarios that uniquely benefit from by local or Internet connectivity.
I’d love to be able to say “Alexa/Cortana/Siri, where did I put the size 3 cross-slot screwdriver?” and I get told “You put it into a box on the second shelf from the top in the right kitchen storage cabinet last time I saw you having it. There’s also one in the toolbox in the garage.” I’d like that a lot more than my screwdriving performance statistics on an app. Really. Go make that.
The “Internet of Things” is not a Silicon Valley startup phenomenon. Adding connected digital capabilities to tools, toys, devices, and machines that surround us at home, at work, and during our fun activities, is something that the software industry will surely be able to help with. But the manufacturers who must ultimately lead in making the “Internet of Things” real are those with experience, depth industry requirements knowledge, supply chain relationships, and capital investments to deliver excellent safe and robust tools, toys, devices, and machines; with digitally enhancements as a secondary capability. Excellent software in an awful hammer still makes an awful hammer.
