When it comes to citing examples of over-automation, improperly applied automation or flawed automation there is no shortage of material to draw from. It’s everywhere. Consider the following scenario: I’ll put my comments in brackets [ ]

THE HOUR website (October 31, 2020) did a story about NASA’s Orion spacecraft in orbit around the moon and they were confident the mechanical components would perform adequately. However they were not confident that the software that was used to control everything the rocket does was up to the task.

Shortly after it reached orbit the spacecraft, which had no astronauts on board, ran into trouble because the flight computers were 11 hours off. [I cannot over-emphasize how critically important this is. Almost everything a computer does is referenced to time].

This caused the spacecraft to lose its navigational reference [it didn’t know where it was so it didn’t know where it should be either] which burned additional fuel which in turn forced the operators to call off the mission early [there are no fueling stations in outer space at this time].

Boeing was able to diagnose the problem and send up a software fix which managed to bring the spacecraft down safely. Later evaluation [often called a “Post Mortem” and for good reason] found that both the software itself and the software testing were deeply flawed [DUH!].

Boeing also revealed that did not use the actual hardware for testing but used instead an “emulator” which is an equipment “simulator” that is supposed to simulate the real world conditions they are trying to test. However this “emulator” had the wrong values programmed into it [which literally transformed this space-ship into a space boat-anchor].

There is no substitute for “hands-on” testing. If you cannot get “hands-on” testing as would be the case here you find the next best thing. You first test all of the components individually and then test them as a unit. This is not a new concept and has been used successfully for many years.

Henry Royce, the “Royce” of the Rolls-Royce automobile manufacturer, was known to abuse his new products in order to determine if they were fit to use in the Rolls-Royce automobile. The idea was that if the product could survive the abuse “in the lab” it wouldn’t have any problem performing in the real world.

When we develop a new product we will often give them to the customer at no charge for testing. We make sure they are working well during bench testing but that’s not enough. If the product has a problem sooner or later that problem will surface. If it performs well “in the field” then, an only then, will we consider marketing that product.

Why do we “give away” merchandise? That would seem to be a poor business model but it isn’t. We give it away because what we learn from the customer feedback is valuable information that can be used to improve that – and other products – long into the future. We never turn down the chance to learn something useful.