Library

6.5 MACHINES REPLACE HUMANS

Since its natural products are machines, a victorious and uncontrolled command technology will naturally tend to surround itself with machines and reflexively shy away from humans. This tendency towards automation tends to disregard the many irreplaceable advantages that often make humans more effective than machines in the performance of certain military functions. The general argument Network Centrists adduce to justify this tendency, gravitates around two points: that machines are more accurate and more efficient than humans in the performance of many, if not all, military functions, and that machines could save the nation a lot of money by replacing more-expensive humans. While the latter might be a legitimate argument, the former is completely misleading because it ignores the crucial point that humans are far more flexible than machines and it does not confront directly the devastating consequences of machine malfunction or collapse in the midst of a crucial military operation. While a human will fight-on even if wounded, an electronic machine will stop working altogether if some of its parts have malfunctioned.

Simple examples of what may happen when machines take over a man’s job abound. One may recall, for instance, the incident when one of the fully automated ships of the United States fleet had to be towed back to port in shame because her engines, though perfectly functional, would no longer bring her back. According to the technical people involved in making the USS Yorktown a smart ship, a sailor operating the computer which ran the automated system, had mistakenly entered a zero in a field of the Windows operating system which did not tolerate such an entry. Probably because it could not divide by zero and the creator failed to tell the computer what to do under the circumstances, the computer suddenly shut itself down and with it the propulsion system [4]:

The Yorktown lost control of its propulsion system because its computers were unable to divide by the number zero. The Yorktown’s Standard Monitoring Control System administrator entered zero into the data field for the Remote Data Base Manager program. That caused the database to overflow and crash all Local Area Network consoles and miniature remote terminal units. The ship had to be towed into the Naval base at Norfolk, VA.

The U.S. Navy put forth a rather different version of events in which it was human error, not computer malfunction, that was responsible for the September 1997 incident and in which the ship entered port on its own power [5]:

Human error, not Microsoft Windows NT, was the cause of a LAN failure aboard the Aegis cruiser USS Yorktown that left the Smart Ship dead in the water for nearly three hours last fall during maneuvers near Cape Charles, VA. The Yorktown was not towed into port as a result of this incident.

In any case, whichever version of events one is inclined to believe, the fact remains that the propulsion system was knocked out of service by a malfunctioning automated system. Should this have happened under enemy fire, the ship may have been lost regardless of whether or not the expertise needed to fix the LAN was available on board.

Incidentally, this example illustrates perfectly the Network Centrist instinct for acquiring technology first and then trying to fix any problems that arise later. As a civilian engineer with the Atlantic Fleet Technical Support Center pointed out [4]:

Installing a control system on a warship and resolving problems as the project progresses is a costly and naïve process.

To avoid such potentially devastating developments, the defense acquisition community should do a lot more up-front engineering before deciding to install a system aboard a combatant.

Endnotes

  • [4] G. Slabodkin, “Software Glitches Leave the Navy Smart Ship Dead in the Water”, Government Computer News, July 13, 1998. back
  • [5] G. Slabodkin, “Calibration Flaw Crashes Yorktown LAN”, Government Computer News, November 9, 1998. back