State of the market: shot in both feet
In 2015, the McKinsey Global Institute predicted that Internet of Things (IoT) products and services will become an $11.1 industry by 2025. “Our central finding is that the hype may actually understate the full potential,” they reported, joining legions of others in buzzing over the potential efficiency gains of making cities, manufacturing, healthcare, homes, and everything else ‘smart’, by which they mean reactive, or connected.
Three years on, it’s becoming clear that IoT is indeed falling short of the hype. A recent survey by Cisco found that 74% of all IoT projects end in failure to deliver, and Silicon Valley is littered with the scattered remains of failed IoT startups.
Why it’s so bad
Something is rotten in the state of IoT technology, but the problem goes deeper than the tech sector’s failure to make connecting sensors to the internet easy and meaningful. The failed projects are a bad sign, but as a technologist, my view is that even those connected products that reach the market are by and large… well, designed amateurishly.
Some are egregiously terrifying, others are face-palmingly flawed, and plenty more are just plain invasive and pointless, but not in a charming ‘maybe-it’s-art’ way.
The fact is, most smart products are fundamentally broken — at a minimum, vulnerable; more often entirely unneeded. We’re creating devices that are tedious to connect, that fulfill an ill-defined or incomplete use case, and that are appallingly open to being hacked, then marketing them under an umbrella of futurism and interoperability that is neither understood nor supported by their manufacturers. These disconnects from practical reality can all be traced back to the way things come to be built, and the organizational systems and attitudes that inform that cycle within our largest global brands. We’ve reached a point where the culture of making things has fallen behind the technology of doing things.
visual.ly
What “good” looks like
When thinking about product innovation, the best example to me of getting it right is the smartphone. Not shockingly original, of course, but the reasons for the mobile computing explosion go well beyond battery chemistry. Technologically, it’s a painfully uninspired product category — a few sensors and a screen hooked up to a battery, and a transmitter. Yet we have shown that the smartphone has an almost unlimited number of use cases: it can order food just as easily as it can track your period. (Admittedly, it’s also gotten pretty bad at, you know, being a phone.)
This incredible versatility comes from a key feature of the smartphone’s design: it is open to being reimagined by app developers and activist users. Nothing has been a bigger determinant of its success.
Though Apple and Huawei and Samsung may have the best product engineers in the field, they can’t deliver one irreplaceable ingredient of a hit product: immediate reactivity to the diverse needs of their users. Experience tells us that kind of reactivity can only come reliably from one place — the community of technically sophisticated users. Unprompted beyond cubicle malaise and a chip on their shoulders about what the future was supposed to look like, they constantly suggest the new (and sometimes ridiculous) uses for existing technology that winds up radically expanding its value proposition for the rest of us.
These activist users acting as product re-developers are best able to produce small, purpose-built hacks or applications that define a “pet project” use case. This constantly evolving list of literal applications is what makes the smartphone so exceptional from a product standpoint. To resist this user-driven forward march would be to take the Tesla in the garage and insist on retrofitting it with a two-stroke gas engine in order to fit what our local mechanic is comfortable with.
Open, reactive, and tuned to the needs of its user base — if the smartphone + app store is the cornerstone of what a modern device is, there are woefully few other examples of smart products that measure up. Opening these devices to their full potential requires thinking through the organizational impediments that are leading to the current state of bad design that we have come to accept as ‘good enough’.
IoT is stuck in an older model
Today’s startups routinely bash the older generation of big tech companies for their lack of innovation. The charges are perennial: large siloed bureaucracies of long-successful enterprises (sorry, Japan) can muddle the development of a product beyond all recognition, sprawling and rigid hierarchies require so much change management that they stop even trying to keep pace with what’s possible. These are truths of working with scale and risk-aversion, however, modern IoT projects more often produce mediocrity because of specific impairments that relate directly to the “openness” of their product’s design. Simply put, veteran hardware engineers lean on the tools they know best, and when all you know is a hammer, everything looks like a nail. Nails don’t build satellites, and they certainly don’t build app stores or secure environments for trustless installing of user-submitted software.
This is to say that the first impediment is laziness. Many IoT companies don’t really have a mechanism for running someone else’s code securely on their platform, and developing one takes time and money, so they simply don’t bother since they’ve ‘never needed it before’. Perfectly rational for each individual firm, yet this classic prisoner’s dilemma is a serious problem for IoT as a field because it creates a culture of bad design and sets the bar for new products very low.
The deeper barrier may be the wider American culture of liability. Without a well-worn method for proactively assessing the quality of external parties’ code—nevermind the possibility that shedding light on their own code would make their engineering teams look bad—most firms aren’t willing to take the risk. To manufacturers, this makes any amount of API opening look more like a burden than an opportunity, especially because the responsibilities of the original equipment manufacturer (OEM) to provide long-term support become grayer the more user-innovation is invited.
techcrunch.com
Opening APIs and source for fun, security, and profit
The good news is that there is a consideration that trumps liability concerns when it comes to product design: open sourcing is *very* good for security. This may seem counterintuitive; shouldn’t opening your code to outside developers open your product to hackers as well? One look at the data will put to rest that misconception. The operating systems powering the vast majority of the most critical systems in the world—66% of web servers, 72% of mobile phones, and 100% of TOP500 supercomputers are all members of open source OS families. [link to Wikipedia is trashy?]
The same logic that tells us that activist user-developers can exponentially increase the usefulness of a product applies to security as well: the truth is that no engineering team, no matter how good, can think of every possible flaw in their code. Professionals are quick to point out that security is a problem that is never solved, only managed, but it is also true that there are good and bad systems to manage it. In an open source system, a group of user-developers can compete with each other to find and release patches to bugs in near real-time. In a closed system, assessing the list of known bugs alone will quickly outstrip available resources. Too many companies simply accept this state of affairs until a security breach actually occurs. This status quo is unacceptable. Assuming that what is hidden from sight is sufficiently secured is how we get botnets, it’s how we get deeply-penetrated deployments of devices with gaping security holes. As security concerns mount, it is imperative that we accept that it is impossible to create the most secure devices possible in a vacuum.
Right now, the road to better contains many low hanging fruits: making it easy or required for users to pick a robust password for internet-connected devices would be a good place to start. In the long run, however, a fundamental change in approach is required. Inevitably, the path forward is one which lets the current generation of smartphone app developers become the product architects and “firmware engineers” of tomorrow by opening our devices to them. When we do, it will spell only good news for the state of technology.