On the evening of May 31, 2014, businessman Lewis Katz and a few of his friends boarded Katz’s private Gulfstream IV jet at Hanscom Field, an airfield outside Boston. They had just attended a fundraising event in Concord, MA, and were bound for Atlantic City, NJ. The aircraft taxied to the runway and was cleared for takeoff. It started its takeoff run and, despite reaching a speed of more than 180 mph, it failed to leave the ground, overrunning the end of the runway and crashing into a ravine. The aircraft burst into flames, killing all seven people on board, and completely destroying the $30m jet.
Accidents like this one are investigated by the National Transportation Safety Board, and after more than a year of investigation, the NTSB published its findings and made a determination of the probable cause of the crash. In common with many other aircraft, the Gulfstream has what is called a gust lock system. This system locks the elevator, ailerons and rudder (the basic directional controls of the aircraft) while it’s parked, to protect them from damage caused by wind gusts. The NTSB determined that the pilots attempted to take off with the gust lock still engaged, preventing them from being able to effectively control the airplane once it had attained takeoff speed.
The Gulfstream IV business jet aircraft has a good safety record. In the period 2000-2015, Gulfstream IVs experienced about one accident for every 600,000 hours flown. That compares to the average across all business jets in the period of 2.6 accidents per 600,000 hours. Also, the pilot and copilot were no rookies. Between them, they had 29,000 hours of flying experience and had worked for Katz for more than 10 years. So how could this tragedy have happened?
The report from the NTSB is pretty clear about what took place. “During the engine start process, the flight crew neglected to disengage the airplane's gust lock system,” it says. “Further, before initiating takeoff, the pilots neglected to perform a flight control check that would have alerted them of the locked flight controls.”
These were a couple of veteran pilots, who had flown this aircraft hundreds of times before. Based on the evidence in the NTSB report, it looks like they skipped at least one of the important parts of the preflight checklist with, in this case, fatal results. A few years ago, a friend of mine offered to take me for a flight in his own light aircraft. I remember feeling a bit awkward as we sat together in the cabin, my friend deliberately reading out loud each item on the checklist and then answering himself as he checked each item. Although it struck me as odd behavior at the time, I’m glad he thoroughly checked everything before we took off.
Personally, I’m a big fan of checklists in everyday work situations, even when people’s lives are not at stake. If you are subscribed to our newsletter email, you’ll know that we send this email out to our subscribers once a month. You probably don’t know that there are about a couple of dozen steps that must be executed correctly, in the right order, to put together the email, send it to the right people, and process any non-delivery reports or unsubscribe requests that we get back. We use a checklist for this. Not because anyone will die if we get it wrong, but because it reduces the chances of making a mistake to almost zero.
In our experience, the one area in the work life of an HCL Notes and Domino professional that could really benefit from using a checklist is when it comes to building and deploying Notes and Domino applications. A build process is something that’s familiar to anyone who’s used compiled languages, but may not be so familiar in the world of interpreted languages and rapid app development (aka low code) environments like Notes.
Even if you have the simplest of Notes/Domino applications, there are certain steps you have to take, in the right order, in order to deploy your application. And, when it comes to rolling out new versions of the same app, it’s important to make sure you always do it the same way, in the same sequence. For example, you need to be careful about how you name and where you place the new version of your design template. You need to make sure the ACL and roles are set up correctly. Agents may need to be enabled to run on the correct server. You may need to sign the database with an appropriate user ID.
If you’re not using a checklist to make sure you do these things consistently each time you make a new release of an app, then you’re missing a simple and easy way to avoid problems down the road. Of course, the gold standard when it comes to build process management is to automate the build, which is exactly what Teamstudio Build Manager does for you. You can easily define a set of actions that Build Manager will perform consistently each time, providing you with an audit log should you ever need to refer back to it.
Surgeons, airline pilots, construction and finance professionals, and many other people use checklists every day to increase efficiency and avoid (avoidable) mistakes. If you make a mistake in the application deployment process, most likely no one will die and it will not cost millions of dollars to rectify. But a simple checklist is a really simple and easy way to make sure those errors don’t happen.
To learn more about Build Manager and how it can help you increase the quality and consistency of your Notes and Domino application releases, click below.