An infinity of interesting problems
In 1944, Grace Hopper was working on the Mark 1 Harvard computer, solving mathematical problems for the US military. The machine had a clock speed of three hertz - three cycles per second. That’s not three million, three thousand, or even three hundred - it’s three. By contrast, today’s processor speeds are measured in gigahertz, billions of cycles per second. In order to get more power out of the machine, Hopper and her colleagues figured out ways to inject more instructions into the machine in what would otherwise have been idle cycles: an early form of parallel processing.
Across the Atlantic, in Bletchley Park, Tommy Flowers faced a similar problem, but adopted a different solution. The Heath Robinson machines intended to break even more complex codes than Enigma, lived up to their name - they were complicated and prone to failure. He proposed to replace the electromechanical relays with vacuum tubes, creating the first ever electronic computer. His colleagues were sceptical, until Flowers and his colleagues proved that a computer could be built from electronic parts, and could run thousands of times faster than the alternative.
In the 1960s, Margaret Hamilton and her team in MIT were writing the software for the Apollo Guidance Computer, the machine that the Moon mission would depend on. The size and weight of the machine were severely constrained, to the extent that the computer architecture only had three binary digits available to encode each command. If you know your binary, you’ll realise that three binary digits only have room for eight numbers - and eight commands are not enough to get a spacecraft to the Moon and back. Hamilton’s team came up with ingenious ways to extend the AGC’s core vocabulary to just under fifty commands - and then built an interpreter to extend the vocabulary even further and code in a language that was easier to understand.
I have been reading a lot recently about the early days of computing (for a project that I will share more details of later on), and have been repeatedly struck by the ingenuity, creativity and determination of those early pioneers. When you work in a mature field, you often feel like you missed out on those days when everything was new, every problem was unsolved, and the future remained to be invented.
Fortunately, I do not think that, in the field of computing, we have to feel this way. There are many lessons we can learn from these early stories, but I would like to explore three today.
We are always on the frontier
We are not currently grappling with exactly the same problems as Hopper, Flowers or Hamilton. We have figured out some of the basics of computing which they had to invent from scratch. However, we are dealing with problems which seem just as fundamental: research and product development across the industry put new capabilities in our hands every day - but don’t tell us how to use them well. Across industry and the public sector, teams are trying to work out how to use AI responsibly and effectively. In a few years’ time, they will be getting to grips with quantum computing. We have not yet found the end of interesting problems.
Hard problems create possibilities
In enterprise computing, projects are often shaped to deliver quick wins, and to tackle the easiest problems first. That makes sense when we are seeking to learn, or to deliver a rapid return on investment. But if we only ever build machines to harvest low hanging fruit, then we will only ever harvest low hanging fruit - which will soon run out. The profound value of computing comes when we push it to its limits, and use it to do things that no-one has ever done before. If you doubt that this is possible in your enterprise context, go and talk to your software engineers: you will often find that they are spending their time on novel problems. There are infinite ways to put software together, even with familiar, tried and tested products - and we have not yet exhausted infinity.
We always need more power, and more people
The processors we have today are billions of times more powerful than the Mark 1 Harvard that Grace Hopper worked on. And yet they are still not enough. Even at the glacial pace of 1944, the work done by the Mark 1 was so valuable that there was intense competition to get time on the machine. Today, that competition takes place at a micro level, as the many different apps you use to run your life battle for resources on your phone, and at a macro level, as companies and countries attempt to secure the precious supply of chips.
Similarly, when Hopper started work on the Mark 1, she was the third person to ever programme the machine. Today we have millions of people capable of writing software - but they are not enough. We need millions more: the number of people who can realise the potential of computing has never approached the limits of that potential.
Two more thoughts. First, Flowers, Hopper and Hamilton came from engineering and mathematical backgrounds. But they got their training in computers on the job, by working with real machines, and inventing basic techniques. I think this tells us that anyone who is interested in exploring the frontier of computing, anyone who is attracted by hard problems, anyone who wants to make an impact using technology, can learn how. The career is open to anybody with an appetite for innovation and hard problems.
Second, these pioneering projects were all examples of public service. Hopper was in the Navy, Flowers was seconded from the Post Office to British Intelligence, and Hamilton was working on a project funded by NASA. The public sector is full of difficult and interesting problems, and always has an urgent need for talented people. Find out more here, or by following Government Digital and Data .
