As a software-engineer, I would never have taken a ride on OceanGate’s Titan submersible. No, it’s not about whether they took safety seriously. We software-engineers famously don’t care about such things. Instead, it’s the lack of the proper type of testing. The sub (“Titan”) was the first deep sea sub to use composites for the hull. They had no experience in how such hulls would fail.
Modern software-engineering is more about testing than writing code. In the past, engineers would try to write code that worked the first time. Now, we assume the code we write is buggy, and instead focus our efforts on searching for those bugs. Our faith in our code comes not from believing we wrote it right to begin with, but that our tests will have found every bug.
There are two kinds of tests that software-engineers create. One test tries to show the software succeeding. The other test tries to make the software fail.
For example, let’s say that a requirement is that the login page for a website must support passwords at least 20 characters long. Some engineers will write tests that send 20 character passwords to see if it matches the requirement. Other engineers will create test that keeps testing with increasingly long passwords, starting from 0, to see at which point the website fails. If it takes a password with a million characters to cause a failure, then that’s something they’ll find. They’ll still mark this as a “success”, because it shows the website handling 20 characters, but at the same time, they pushed all the way to “failure”.
A real-life example is how Boeing tests the wings of new airplane designs. This video shows testing the 777 wing all the way to destruction. They keep applying more and more load until it breaks. You can’t truly know something until you cause it to failure.
The problem with the first kind of test, merely testing if something works, is that it leads to confirmation bias. People want the test to succeed. When they come across failures, they sometimes question the test: maybe it’s the test that’s at fault? Instead of fixing the code, they sometimes fix the test, so that it no longer shows a fault.
You’d think this is crazy but this is how most software-engineering organizations work. It’s a cultural thing, it’s human nature. Ultimately, all that matters is shipping the final product, and engineers who get in the way of doing that are considered trouble makers.
Strong leadership fixes this. They take control of the organization culture and push policies like testing-to-failure.
Such aggressive testing is what produces superior software. You can’t trust software until you’ve pushed it to it’s breaking limits.
That’s the flaw I see here with OceanGate’s CEO, Stockton Rush. It’s not that he ignored safety, but that he did the wrong things to assure it. I think people claiming he dismissed safety concerns are taking things out of context. I think he cared about safety, but did the wrong things to assure it.
This was the first deep sea submersible to use carbon fiber composites. It has known issues, such as imperfections developing during manufacturing as well as repeated dives. He invented ways to detect such flaws live, as the sub was descending.
But he didn’t test these to failure. He didn’t create a prototype sub and send it on repeated (unmanned) dives until it failed.
All indications are that the system worked, that as they were diving toward the Titanic, the system detected flaws developing, so they started rising. But they were too deep at that point and couldn’t rise fast enough. It appears the spreading flaws outraced their climb, causing an implosion.
This is the sort of problem you’d find if you’d tested to failure. You see that while the system did detect flaws developing before complete failure, that it still failed to detect them in time.
Going the other direction, Elon Musks employs this strategy with his rockets. He’s blown up a lot of rockets. He’s had a ton of failures in the early stages. SpaceX has more experience with rockets failing than his competitors. But at the time, he now has the best track record of successes, not simply launching rockets, but bringing them back to Earth safely.
Whenever there’s a big failure, people will blame somebody for neglecting safety. As a software engineer, I don’t believe that’s a thing. Every release of software is a debate between one side claiming it’s not ready and another claiming it’s good enough. When failures happen, suddenly the naysayers are given credit, even though they usually were right for the wrong reasons. For example, in this case, people point to a whistleblower concerned about the window being unsafe, when the the likely cause is a completely different failure. Being morally right trumps being technically wrong.
Thus, as a software-engineer, I wouldn’t fear negligence on the part of OceanGate. The CEO himself was the one piloting the craft. Instead, I blame stupidity. He did the wrong sort of testing. He got several safety-related patents. It’s just that getting a patent doesn’t prove it actually works. He wouldn’t know how well it works until he tested to failure.
I worked as a ME Tech for 5 years at a company that made residential water processing equipment. We produced many of our own parts via injection molding, and out of a variety of raw materials. One of my responsibilities was to run water-pressurized cycle tests on a specified number of our parts and assemblies, at 3x the psi of the highest municipalities in the country, and run them until they failed. We did this for every run of parts, and still had occasional failures in the field. Because we put our product through such rigorous testing though, they were few and far between.
I left that job in 1996, but I can guarantee those tests are still being run today. It was insurance of sorts, and the original owners of the company would never have had it any other way. They were both Engineers, and good ones at that. Two of the most intelligent men I've ever had the pleasure of working for, and they knew the value of that testing enough to visit my little corner of the shop on occasion just to see how things were holding up. I can't imagine the damage that could be done to people's homes without it. I would not have had that job, because the company would never have stayed in business, but for those cycle tests.