Repurposing Turing's "Human Brake"

In 1945, Alan Turing theorized one of the major stumbling blocks to computing technology's potential, coining the term "the human brake." The human brake slowed computing processes by delegating actions to human operators that should ideally reside within the capabilities of a machine and its programming.

Turing went on to outline a stored program computer that aimed to revolutionize the current state of the art. Holding programmatic instructions for data manipulation within the machine would vastly increase the rate of speed at which input and output could be run through the central processor. Eliminating "all that is done by the normal human operator" and transferring these functions to the machine, not only increased speed but also would, it was hoped, reduce the level of error.¹

In the strictest sense, Turing's human brake as then articulated is barely recognizable today as an impediment to computing speed and efficacy. But in a broader sense, the human brake has never left the field of electronic computing. It has become transformed over the course of its historical trajectory, becoming increasingly abstract rather than being outright eliminated.

This essay aims to provide a brief historical discussion of incarnations of the human brake throughout the 20th century. My hope is that by slightly stretching and reorienting the concept functionally, while trying to remain true to its theoretical roots, we can create a useful tool for rethinking aspects computing's future as well as its past, as Turing did in 1945.

Starting from this materially based analogy may hold great benefits for understanding the increasingly abstracted work processes made possible by successive generations of data processing systems. The historical vignettes offered come from the British context, both because of the pioneering work done there and the focus of my research. I conclude with an attempt to relate the human brake concept back to modern American, and global, computing systems and solutions.

In the 1950s, early computers propagated into a wide variety of administrative uses in commercial and government offices, moving away from being used primarily in scientific and military operations. Arguably, labor interaction with the technology became increasingly complex and multifaceted as a result. As the expansion of electronic computing's applications enabled it to replace electromechanical office automation, both its scope and purpose began to shift.

At that point, the human brake still existed, even in the realm of stored program computers. Their functioning, though ideally automatic, often required an enormous amount of behind-the-scenes operational troubleshooting. The earliest business machines were adapted for use by the British bakery, Lyons. Modeling them on the Cambridge EDSAC, the company engineered and programmed them in-house to tailor them to specific work processes; primarily inventory and payroll needs.² Nevertheless, one LEO operator recalled, "the earliest machines were very temperamental…Some of the early applications needed a lot of nursing."³

Clearly, the human brake had not evaporated with the advent of stored-program computing, though its contours had begun to change. Its presence was now much less a result of functional incapabilities engineered into the computer. Rather, intermittently faulty programs or hardware, combined with lagging peripheral design, continued to animate the concept.

The idea could also be expanded to encompass other kinds of "braking" effects. One clear-cut legacy of the human brake present in Britain throughout the 1960s involved requirements ancillary to machine operation and maintenance, but crucial components of the system nonetheless.⁴ Even when programs ran seamlessly, hardware was in good repair, and operators worked efficiently, machines might fail due to the built environment of machine rooms.

Recalling an overly-spectacular failure at LEO, operator Colin Hobson painted an image of a machine room barely recognizable under current definitions:

One very hot summer we were working, stripped to the waist, with all the windows open, when a plague of newly hatched black flies came in from the playing field opposite. They got everywhere and caused data failures when the card readers tried to read them.³

A host of similar infrastructure problems were regularly present. Dampness ruined input by deforming cards, improper electrical supply or grounding damaged machines and peripherals, rising humidity...