There is little in our lives that does not rely on software. That has been the reality for quite some time, and it will be even more true as self-driving cars and similar technologies become an even greater part of our lives. But as our reliance on software grows, so does the potential for disaster as software becomes increasingly complex.
In September 2017 The Atlantic featured “The Coming Software Apocalypse,” an article by James Somers that offers a fascinating and sobering look at how rampant code complexity has caused massive failures in critical software systems, like the 2014 incident that left the entire state of Washington without 9-1-1 emergency call-in services until the problem was traced to software running on a server in Colorado.
The article suggests that the core of the complexity problem is that code is too hard to think about. When and how did this happen?
“You have to talk about the problem domain,” says Chris Newcombe,”because there are areas where code clearly works fine.” Newcombe, one of the people interviewed for the Atlantic article, is an expert on combating complexity, and since 2014 has been an architect on Oracle’s Bare Metal IaaS team.
“I used to work in video games,” Newcombe says. “There is lots of complex code in video games and most of them work fine. But if you're talking about control systems, with significant concurrency or affecting real-world equipment, like cars and planes and rockets or large-scale distribution systems, then we still have a way to go to solve the problem of true reliability. I think it's problem-domain specific. I don't think code is necessarily the problem. The problem is complexity, particularly concurrency and partial failure modes and side effects in the real world.”
Java Champion Adam Bien believes that in constrained environments, such as the software found in automobiles, “it's more or less a state machine which could or should be coded differently. So it really depends on the focus or the context. I would say that in enterprise software, code works well. The problem I see is more if you get newer ideas -- how to reshape the existing code quickly. But also coding is not just about code. Whether you write code or draw diagrams, the complexity will remain the same.”
Java Champion and microservices expert Chris Richardson agrees that “if you work hard enough, you can deliver software that actually works.” But he questions what is actually meant when software is described as “working well.”
“How successful are large software developments?” Richardson asks. “Do they meet requirements on time? Obviously that's a complex issue around project management and people. But what's the success rate?”
Richardson also points out that concerns about complexity are nothing new. “If you go back and look at the literature 30 or 40 years ago, people were concerned about software complexity then.”
The Atlantic article mentions that in most cases software does exactly what it was designed to do, an indication that it's not really a failure of the software as much as of the design of the software.
According to Developer Champion and Oracle ACE Director Lucas Jellema, “The complexity may not be in the software, but in the translation of the real-world problem or requirement into software. That starts not with coding, but with communication from one human being to another, from business end user to analyst to developer and maybe even some layers in between. That's where it usually goes wrong. In the end the software will do what the programmer told it to do, but that might not be what the business user or the real world requires it to do.”
Communication between stakeholders is only one aspect of the battle to reduce software complexity, and it’s just one issue among many that Chris Newcombe, Chris Richardson, Adam Bien, and Lucas Jellema discuss in this podcast. So settle in and listen.
This program was recorded on November 22, 2017.
(In alphabetical order)
Oracle ACE Director
CTO, AMIS Services
Oracle Developer Champion
Oracle ACE Director
Architect, Oracle Bare Metal IaaS Team
Founder, Eventuate. Inc