I recently came across a thought-provoking article on The Atlantic about "saving the world from code" and how software...
can mean life or death for almost all of us on the planet. Software has kept our hearts and cars running for a minute, but it has an imprint at every level of society.
"The Coming Software Apocalypse," by James Somers, a programmer and regular Atlantic contributor, shares some sobering examples of tragic software failures and how software controls many of our society's most vital services.
For example, software controls 911 call routing. And for about 40 minutes in 2014, the entire state of Washington lost the ability to reach help dialing 911, all because of one faulty line of code.
The major software failures now mean literal life or death. Other examples include Toyota vehicle acceleration errors causing fatal accidents because of a software malfunction and medical radiation therapy killing patients. This is scary stuff.
Even for someone deeply entrenched in the world of technology innovation, I am amazed at how software has taken control of so many aspects of our lives and how lines of code control activities we don't even realize.
In his piece, Somers detailed the dangers of our current development practices. Software, as it's created and delivered today, is subject to human error, primarily because the developers are so disconnected from the end product of their work.
Vehicle braking systems, for example, involve complex and massive programs with millions of lines of code. In the old days, braking systems consisted of metal parts. Fifty years ago, mechanics could easily see the cause and effect of making changes within the vehicle and could visually identify problems. Today, software failures require examining complex code, and creating these mechanisms is merely conceptual.
Why the future of IT jobs may give techies a pass
Automation is here, and IT departments will never be the same. Data scientists have become the watchdogs of this change, bringing analytics to the masses. Here's a guide to the future of IT jobs.
Can DevOps success prevent tragic software failures?
While certainly there've been tragic failures of important software, one could argue the potential and promise of these innovations is far greater. So, let's focus on the risk of using software for mission-critical operations that Somers pointed out, and let's look at solving that challenge.
"The problem is that software engineers don't understand the problem they're trying to solve, and don't care to ... they're too wrapped up in getting their code to work."
And he'd later write:
"Programmers were like chess players trying to play with a blindfold on -- so much of their mental energy is spent just trying to picture where the pieces are that there's hardly any left over to think about the game itself."
It's exactly this problem that led to the first DevOps movements -- developers didn't seem to have empathy or awareness of what happened to their code after it was passed to operations. And vice versa, the business was not including developers enough in the bigger picture to help them focus their efforts. This problem was identified some time ago; in fact, it's part of the reason Agile practitioners started holding interactive meetings -- to help developers see how their individual part fits into the whole.
So, it's not as if the software development community is unaware that "creators need an immediate connection to what they're creating," as Somers wrote. That's exactly why we're seeing DevOps success, and DevOps movements like it are resonating with companies worldwide. They see the value, particularly in preventing tragic software failures.
Somers mentioned that software development should be geared toward creating tools for developers that make code more reliable and connect developers to the end product they are working on. And he is exactly right.
Tools that make code reviews and versioning simple and clean help prevent spaghetti code. Also, adding transparency and visibility into the development process improves developer performance by giving needed accountability, traceability and teamwork.
Somers' argument is just another confirmation of the need for a better software development lifecycle, one that builds on existing code and prevents errors through continual visibility, traceability and feedback loops. The answer to developers being disconnected to the end product or purpose of their work can largely be solved by implementing DevOps movements and creating an environment of cross-team collaboration.
I would be remiss not to mention open source software as a solution to this problem, as well. Contrary to initial opinions, open source software is safe and reliable, and many organizations -- even government organizations -- rely on open source to run mission-critical programs. Open source offers the needed teamwork, cross-checks and regular improvement that only can happen when you' have input from a broad community.
I encourage you to read "The Coming Software Apocalypse" and share your thoughts. How's your organization working to overcome problems like spaghetti code and outages? How are you using DevOps to connect developers to the end product or the customer experience?
Is DevOps just a buzzword or will the movement have long-term consequences?
Automated software quality metrics can cut costs and boost efficiency
Expert Peter Walsh talks DevOps misconceptions