The marriage of hardware and software is no longer a niche trend in product design. With the growing phenomenon, The Atlantic recently ran a piece, titled “The Coming Software Apocalypse,” about the serious challenges industries face when developing products that rely on both hardware and software, and the real-world consequences occurring as a result.
According to Nancy Leveson, a professor of aeronautics and astronautics at the Massachusetts Institute of Technology, it’s not always a matter of problems with software code. Instead, one of the toughest obstacles of merging hardware and software is engineers being too concerned with getting code to work correctly, instead of focusing on the solution the product is supposed to provide. “The serious problems that have happened with software have to do with requirements, not coding errors,” Leveson tells The Atlantic.
What Could Go Wrong
The article details terrifying, real-life stories of hardware and services malfunctioning due to issues with implemented software, including a car being unable to brake on a highway and 911 dispatch software leaving 11 million people without access to emergency response.
In the case of the 911 outage, cell phone technology drove changes to the 911 infrastructure, causing the issues. The Atlantic states that emergency calls traditionally were handled locally – less risk, but less technological advancement. The spread of smart phones brought about all sorts of supplemental possibilities to facilitate 911 services, such as texting instead of calling or sending videos to dispatchers. These prospects pushed more complex, connected systems for 911 to be developed. And it’s these advanced systems that contributed to the outages.
The updates to 911 services mirrors similar changes in many other industries, where the rapid adoption of internet-driven technologies over the past decade has pushed companies to add connectivity to everything from vehicles to personal accessories.
Given the evolving demands of the consumer, the speed at which these devices are being produced, and the increasing complexity of the products themselves, problems like the aforementioned have emerged. Leveson gives The Atlantic an excellent diagnosis of the complexities of today’s software issues: “The problem is that we are attempting to build systems that are beyond our ability to intellectually manage.”
As The Atlantic points out, previous generations of engineers could prove a creation reliable by testing all of its physical parts. A problem with a new bicycle, for instance, could be discovered by checking its tires, spokes, chains, etc. With software code, as Leveson notes, the complexities are “invisible to the eye.”
Getting Requirements Right
Requirements are a huge part of making sure products are built the right way. It’s not just enough to have requirements though; they have to be expressed clearly and effectively to all stakeholders. Otherwise, you risk leaving those tasked with creating each piece of the product to interpret things for themselves, resulting in all kinds of problems — including building the wrong thing, costly reworks and missed market opportunities.
And, as mentioned in the article, misunderstanding requirements is a common ailment for development teams. When a requirement is written ambiguously, for instance, the person responsible for coding or building it may interpret it differently than was the intention of the person who wrote it. Requirements also change throughout the development process, through both internal and external feedback, for instance, which also creates opportunities for the introduction of error.
And, with so many products being hardware-software hybrids, it’s made their development a lot more complicated. For instance, vehicles with connected technologies now include millions of lines of code — related to everything from acceleration to parking assist features. In such cases, changing even one line of code, intentionally or not, can set off an unintended chain reaction that devastates a product. With so much information, it’s impossible for the human brain to account for all of the variables that can occur when it’s altered.
Better Requirements Management
A solid requirements management solution can solve several of these challenges. A good requirements management platform improves the end result by facilitating collaboration, traceability and testing. It also assists with fulfilling compliance in regulated industries, cutting down on risk and allowing for verification and validation.
Not only that, but a good requirements management platform allows team members to provide feedback in real time, cuts down on meetings and provides more time to focus on ensuring quality and getting the product out the door.
Requirements management alone won’t solve all the issues raised in The Atlantic’s article, but it is definitely a step in the right direction. The introduction of integrated software to so many traditional products — especially devices and services we have come to rely on for our own safety — means requirements have become too complicated to languish in antiquated document or legacy software.
Instead, companies need to rethink their processes when developing software-infused products, and partnering up with outside organizations is one way to do that. For instance, according to the recent report, “Bridging the Gap in Digital Product Design,” more than half of businesses building complex, connected products are teaming up with software or other companies to improve their abilities and processes
The faster organizations creating complex products realize the benefits of using different platforms and methodologies, the better off we’ll all be. And hopefully we can avoid anything close to a software doomsday.