When people hear the term software developer, they probably don’t think of a career that involves individuals holding people’s lives in their hands. The reality is though that for some who are writing software, it could mean life or death. Consider things like autonomous software for Tesla –mess that up and it could mean death. Drug to drug interaction checking –this can also cause death. There is definitely a difference in writing software for video games vs writing software that flies airplanes. We are going to hope that that is one that absolutely needs to be right.
People who write this sort of software are not just average scripters. You don’t want the lives of people in the hands of someone who doesn’t entirely know what they’re doing. Mistakes here can be deadly. Consider for a moment places like NASA. Here the software is taking command of a 120-ton space shuttle.
From Fast Company:
The development group is supposed to deliver completely error-free code, so perfect that the testers find no flaws at all. The testing group is supposed to pummel away at the code with flight scenarios and simulations that reveal as many flaws as possible. The result is what Tom Peterson calls “a friendly adversarial relationship.” “They’re in competition for who’s going to find the errors,” says Keller. “Sometimes they fight like cats and dogs […]”
The key is to prevent any errors from happening first by not making errors and then by checking anyway to find all the errors that you can. Is it worth it for software development consultants to get involved in life or death development? When people’s lives are on the line, you should be absolutely certain you know what you’re doing and you know the risks involved.
There are some that take a different approach than NASA on the “life or death software” front. For instance, Stefan Harms is a resident in the department of anesthesiology at the University of Manitoba in Winnipeg. He wants to develop anesthesia software to help better monitor and record patient data while conducting a real-time model of the effect of different drugs and then control the infusion of those drugs. He is going the open source route.
From Salon:
Harms founded LAMDI, the Linux Anesthesia Modular Device Interface. Harms thinks that the open-source software development model, in which the source code to a program is made freely available to the general public for redistribution and modification, offers fruitful possibilities for addressing anesthesiological software needs. Harms is placing his bets on a central tenet of open-source ideology — the belief that freely available source code encourages a “peer-review” process that produces software that is less buggy and more reliable than proprietary “closed-source” software. The theory is that when everyone can hack on the code, fix problems as they find them, and add their own new features, the code quickly improves.
There are obviously different views of what life and death software development should look like. When software moves beyond a scheduling program and becomes something as important as air traffic controlling, should there be standards across the board that developers have to adhere to? The problem of software product liability is a big issue. Software can be life or death in many scenarios. Where do you think the liability falls with this sort of software? What sort of requirements and guidelines should be tied to this sort of software? What are your thoughts? Comment below!
