Today, I searched for “urgent security fix timeline software development” and found this article from 2017. It was the second result in my search.
Google did a good job with the search results, as usual. I find this article on “The Coming Software Apocalypse” immensely interesting. In 2017, it took 6 hours to fix a bug that brought down the 911 system of Washington state, USA. The fix was changing the value in a variable used as a counter. So, in this case, an urgent fix took 6 hours. (I wonder: The failure happened at midnight. Would it have taken as long to fix if it had happened during business hours? Did it take that long because of the complexity of determining the cause, or was it just because the person with the system knowledge was sleeping? The article does not provide those details. But complexity is discussed. )
- It took 6 hours to fix a bug that was causing a statewide 911 outage. 911 is the emergency number people call when there’s a crisis. I would say that this is an extremely urgent bug.
- I would guess that a unit test could have caught this issue. Did they write one after this incident?
This is the trouble with making things out of code, as opposed to something physical. “The complexity,” as Leveson puts it, “is invisible to the eye.”– Leveson, MIT software-safety expert
The Problem: Code is Complex
The programmer, the renowned Dutch computer scientist Edsger Dijkstra wrote in 1988, “has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.” Dijkstra meant this as a warning. As programmers eagerly poured software into critical systems, they became, more and more, the linchpins of the built world—and Dijkstra thought they had perhaps overestimated themselves.
Developers have to translate natural language requirements into extremely precise code
“The serious problems that have happened with software have to do with requirements, not coding errors.”– Leveson, MIT software-safety expert
“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”– The Coming Software Apocalypse