A Computer Called LEO

Posted on 8th Jun, 2014

Recently I came across a blog post on the first Business Intelligence project. This project was run on LEO, the first commercially used computer in the world. The book "A Computer Called LEO" by Georgina Ferry tells the story of how this computer came to be, and how it was used. Where the blog post focuses on the BI part of this book I would like to draw even more parallels to the current state of IT in general. It seems some things never change.

The book "A Computer Called LEO"

J Lyons & Co LTD was a company that owned tea houses, restaurants, bakeries and hotels. Because of the huge size of the company, they employed a lot of clerks to compute pay rolls, orders and such. After WW2 the company invested in what was then predominantly an academic project, computers. While they succeeded in building a computer that could take over a large part of the clerical force, the UK market proved too small to compete with IBM from the United States. The following challenges played a part in the building and use of LEO, and are still challenges now.

Limited bandwidth. Where the computational part of the LEO could do thousands of calculations each second, there was no way to feed information into the system fast enough. Computers used in academic circles and for defence projects in WW2 solved complex computations on only a few variables. To compute payroll data information a series of simpler computations had to be performed for a large number of employees. Today the CPU still often has to wait for data to be read out of the much slower RAM. Computations that are the most useful in "the cloud" are those that do not need a huge amount of data. In the cloud computational power is cheaper than storage and bandwidth.

Programming mistakes. After the first program on the LEO failed to run, the team wrote all software modular, so errors could be tracked down more easily. Going even further, programmers had to create flow-charts for all programs they created. Nowadays it is still considered important in large projects that all parts of the program are first modelled (in for example UML), then programmed.

Reliability. Before the transistors computers used vacuum valves. These valves were not very reliable, and with thousands of valves the computer broke down often. While it is not very common any more for a personal computer to break down during its economical use, it still can be a problem. For instance when using 100s or 1000s of computers at the same time. The Hadoop framework is currently a popular framework to split computational tasks over a large amount of machines. One of the things it does very well is to check if individual machines are still operational, if not, the task assigned to that machine is rescheduled to another one.

Exaggerations of capabilities. Back in the days the capabilities of computers were greatly exaggerated in the media. The Big Data revolution that is currently going on has the same buzz hanging around it.

Fear of job loss. When one of the engineers of the LEO project told their vision of replacing clerical workers for administrative work to a friend, her reaction was that the machine should be destroyed. The loss of jobs is a fear that goes way back. The Luddites are a famous example of a group that protested against having their work replaced. Today it is still a big factor in automation project failures: The Dutch newspaper NRC recently had a big article about IT project failures for the Government. Most projects are aimed as a way to cut down expenses, primarily salaries. It should shock no one that employees have no interest in helping employers to make them redundant.

Time overrun of the project. The LEO was planed to start doing clerical tasks in 1951. It took the team an additional two years to get the system up and running. From that point it shadowed the manually computed pay rolls. A year later, from 1954 it actually got to ride without training wheels. According to the book, it never failed to produce the pay rolls on time. Time and cost overruns are still a problem today in large projects. The Agile project management technique is just one of the attempts to tackle this problem.

To conclude

What an exiting times the early days of computing must have been! With that said, I'm very happy to be able to write this on a lightweight laptop computer, to be able to post these thoughts on the internet and manage my articles via a simple web-interface. For all the things that have stayed the same, so much has changed in those 60 years.