Matthew Kirschenbaum: My name is Matt Kirschenbaum. I am here from MITH who is co‐sponsoring this talk with HCIL, the Maryland Institute for Technology in the Humanities. And I also teach in the English department here. I wanted to volunteer to introduce Thom and Mark because I’ve often said that Thom Haigh here is responsible for saving a year of my life. And what I mean by that, when I was researching my book on the literary history of word processing, Thom’s prior research on word processing was an enormous resource and sent me in many directions I never would have come across otherwise. So Thom saved a year of my life.
He’s also one of the very best computer historians working today, as you will see and hear in just a moment. He runs the Special Interest Group on Computers, Information and Society, which also offers its members that rarest of wonders nowadays, an active, vibrant, and productive listserv, and that’s largely due to Thom’s stewardship of that space. He is currently an Associate Professor in the Information School at the University of Wisconsin Milwaukee.
Mark Priestley… So, I cannot claim that Mark has saved a year of my life. I’ve only just met him.
Mark Priestley: Give me time.
Kirschenbaum: I can tell you that Mark Priestley, who will be co‐presenting with Thom Haigh, is an independent researcher with a a PhD and Science and Technology Studies from University College London. Before that, he worked for many years as a programmer and software developer, and Thom and Mark, and I believe one other individual are the co‐authors of ENIAC in Action just published by the MIT Press.
So take it away, guys.
Thomas Haigh: We’re very please and excited to be here. The book is available now. They are beautifully produced. And they’re merely $38 despite the absolutely lovely quality production. So even if you don’t like the words, you’ll love the pictures.
Now, the book really does a number of different things. Some of what we’re doing in it is in some ways the most in‐depth, technologically involved reconstruction of programming practice that’s ever been attempted. We also do some things that if you have an interest in in the history of computing kind of on the geekier side of it, if you want to know why modern computer architecture is the way it is, you’ll find an explanation here that’s different from anything that’s been presented before. If you want to know you know how and where John von Neumann’s “First Draft of a Report on the EDVAC” is coming from, etc.
But one of the privileges of of writing a whole book on a single artifact is that with that narrowness of scope, in some ways we can be very broad in other ways, so in terms of the questions we engage with, the disciplinary perspectives that we try to incorporate, and the time scale. So the book doesn’t stop, as most people do, seventy years ago this week when ENIAC is unveiled to the public. It doesn’t even stop in 1955 when ENIAC is decommissioned. It goes right up to the present day. The last chapter is basically ENIAC in cultural memory.
So it does a lot of different things. When I was writing it, I think I had a sentence in the introduction which Mark persuaded me to take out that basically anyone is going to be bored by this book at by some point depending on what perspective they’re coming from, but hopefully everyone will find something of interest in it.
And we have these cool posters. I didn’t realize how many people would be here, but I think there are about a dozen of them. Mark is going to kind of briefly explain to you what this inscrutably technical but very attractive flow diagram means.
The part I’m focusing on here, as the title tells, is basically the labor history side of ENIAC, not so much the technical side from the book.
We should thank our sponsors. The research is sponsored by Mrs. LD Rope’s Second Charitable Trust and Third Charitable Trust. We’d like to thank some contributions by [Ann Graf, Peter Sachs Collopy, and Stephanie Dick.]
Conventional History of Computing
So, the conventional history of computing was dominated in its days, and still is if you ever read the comments on a popular article, it’s always battle for firsts. Was it Atanasoff, or Alan Turing, or Atanasoff, or Konrad Zuse, or Eckert and Mauchly who did ENIAC, that invented the first computer? This is a question that computer historians are not, frankly, very interested in. But it seems to obsess with the popular kind narrative.
You see this most clearly here. Alan Turing in The Imitation Game, played by Sherlock Holmes as essentially the same character, right? The autistic, lone, insanely brilliant genius with no relation to anything actually exists in humanity. At some point he turns to the other brilliant codebreakers. Now, Bletchley Park seems to be about six people in the movie, but the other five are mostly just there to be not as smart at Alan Turing. And he says, “I don’t have time to explain myself as I go along. I’m afraid these men will only slow me down.”
So he builds this computer single‐handed, literally. There’s a montage: Turing builds the computer. And it’s not actually a computer. And in reality, the bombe… There were more than ten thousand people involved in the Bletchley Park codebreaking effort. The things were manufactured on an industrial scale by real manufacturing companies. They weren’t even built at Bletchley Park, still less by Alan Turing with his bare hands. But there’s something about that myth of the lone genius that we’re very attached to.
That brings us to Walter Isaacson. And me attacking Walter Isaacson is like a gnat attacking a battleship. It really isn’t going to have very much effect on the world. But there are some good things about this book. He does stress teamwork, lively writing. He has footnotes and references to scholarly history. Some of my colleagues actually received it surprisingly well. But to me, that subtitle there, “How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution” really tells you everything that is desperately, terribly wrong with the book.
Do you get a sense of quite how Walter Isaacson is dominating the world? This is Amazon’s top 10 in Computer Industry History. You’ll see the first five places are different editions of Isaacson, as are two more of them. But the only thing that gives us any hope is up here in the corner, Track Changes: A Literary History of Word Processing. And he was schmoozing with the schmoozers at Davos. He is in kind of elite circles.
So when I read this, I thought well it’s interesting he’s stressing teamwork but he’s also basically…all his characters are presented as superheroes. And I thought, “Where have I seen that before?” It’s basically they’re still superheroes, but they have to work together to change the world. And I mashed things up in a column that’s available for free download in Communications of the ACM to make “Innovators Assemble: Ada Lovelace, Walter Isaacson, and the Superheroines of Computing.” Some of the points that I make here are developed there.
Similarly, ENIAC is one of a succession of “Great Machines” that people tend to somewhat fetishize. So, it’s basic life story, because I know not all of you will have memorized this. It starts in ’43 with the idea. Detailed plans had been drawn up in ’44; prototype and work in construction begins. By the end of ’45, it’s finished and debugged. It’s in experimental use through ’46 at the Moore School at the University of Pennsylvania. But in ’47 it’s moved to the place that actually paid for it and will use it for its productive life, the Ballistic Research Lab at Aberdeen, Maryland, where it’s decommissioned in ’55.
Now, one of the things that you don’t get in the existing history at all, basically, is any sense of what happens to ENIAC after it’s unveiled. It does appear in the computing history. This is a tree from the 60s showing basically all the computers built up to that point. And where is ENIAC in this? ENIAC is the root of the tree from which everything else grows. And that’s how it’s tended to be seen in computer history.
The other thing, when historians decided we really didn’t want to take part in these violent and bloody battles over what was the first computer, we basically sent all the pioneers home with a prize. So we agreed on a string of adjectives to insert between the word “first” and the word “computer.” So ENIAC got the first electronic, digital, general‐purpose computer. And that’s kind of remembered as a step forward to the next big innovation, the first stored‐program computer.
This is a nice chart from Arthur Burks, kind of how it all that fits together. A bunch of things go ENIAC, which passes them on. But before you get to the modern computer we all care about, you have to add this other stuff. Von Neumann and delay line architecture, etc.
So, ENIAC’s place in history kind of reminds me of this guy here, John the Baptist. It’s an important place in the story, but its job is to herald the thing that you’re all really really to find out about, which is either the stored‐program computer or Jesus.
So to sum it up, conventional computer history is obsessed with firsts. It reduces all the materiality and richness and practice of each computer to its single date of first operation. It’s presented as a series of brilliant ideas, the more abstract the better, which is why everyone loves Alan Turing despite the fact he had essentially nothing to do with the invention of the modern computer. And it doesn’t care what computers were actually used for. And what we’re trying to do in the book is to fill in, in one way or another, basically all those missing pieces.
I’m going to sketch some of that history for you here. Actually building it. I mean, it’s a real machine. It has to be built. It doesn’t just—, “Oh! Good idea.” Look, there’s the computer.
It’s built at the Moore School at the University of Pennsylvania, which had had strong ties to the local electronics industry. Something no one remembers is Philadelphia used to be the center of radios, and radios were the main consumer use of electronics. So it was really a hub for electronics manufacturing at that time. It had already partnered with the Ballistic Research Lab to build this thing, an electro‐mechanical differential analyzer that was operated by women to carry out computations. It was a relatively small engineering school, at least compared to MIT which was just hugely bigger and better‐funded.
The project initiators were John Mauchly, a physicist who had seen more opportunities converting to electronics, and Presper Eckert, the star electrical engineering student who’d been recruited to run the laboratory.
The sponsor, the Ordnance Department, what they wanted to do with it was one very specific thing. The whole project was paid for to do one thing, which was to create firing tables. So, most people in World War II died basically from munitions artillery. And when you fire the shell, you need to know where it’s going to land. You can’t just point it, you have to look up in the table what angle you need. It’s basically Angry Birds.
So they needed to work these tables up and they couldn’t computer them by hand fast enough to send the weapons to the war in Europe with them. So it was justified in terms of the urgent needs of World War II.
Now, these guys are reasonably well‐known. You find their names in the history. They’re the engineering team.
But there’s other kinds of work involved with the project that tended to be forgotten that I think are essential to the work of innovation. From the Dean to [inaudible]. The faculty member who’s the official Project Director. But also people like the secretary, the longest‐serving draughtswoman, a Professor who helped them work out the mathematical methods to know how they should build what precision, how many digits the machine needed, how to avoid rounding errors.
The BRL, Herman Goldstine was the BRL person responsible for overseeing work at the Moore School, but he really became a core part of the project. He kind of went native and was pretty much rooting with the team. And his bosses at BRL, the users at BRL who were doing computations and who the machine was being built for also kind of helped to shape what it would be like.
As I mentioned, it was constructed to a degree that really hasn’t been appreciated from careful mathematical analysis of the firing tables problem. But it could tackle many other kinds of problems. So it had a degree of generality there that was unprecedented. And it could achieve this because of its unique architecture. So, the talk’s called “Working on ENIAC,” it [could also be?] called “Working in ENIAC” because the machine was basically a set of room dividers, and they formed an inner room inside the real room, which the operators stood inside. When it moved to BRL, it was the only air conditioned place in the Center, so in the summer people would move their desks inside the computer just to avoid the head and humidity.
And it had the flexibility because connections weren’t hard‐wired between the different electronic parts. They were wired as needed for a particular problem. So setting the machine up to run a program essentially involved using a modular kit, which reminds me of the Radio Shack 201 electronic kits, to run the wires together to make the special‐purpose computer you need for a particular job.
It finished up costing like half a million dollars. Anyone who’s been involved with a project that promised to build something may understand how that could happen when the budget started out as $15,000. It filled about 2,000 square feet, weighed 30 tons, used 150 kilowatts, comparable to modern large‐scale data center equipment.
On the other hand, its memory rather small at 200 decimal digits of read/write memory, 4,000 digits of changeable Read Only Memory. And it could do about 300 multiplications a second, which was absolutely unprecedented at the time.
To give you a sense of the materiality of the thing, you can kind of see all those beautiful joints there, that kind of electronics. People talk only about the vacuum tubes because that was an unusual thing, but those other components, the kind of work that went into them, were equally important to the success of the project.
This is a 1962 photo, frequently mislabeled, showing several generations of computers at BRL. How big one decimal digit was. So this lady here is kind of managing to smile while staggering under the weight of a single decimal digit. And by 1962, you could kind of just hold a digit like this, and obviously they’ve gotten a little smaller since then.
Also, with my interest in business and labor history, this made me think about some sides of the story that really haven’t been talked about at all. Like, during wartime how do you procure this stuff? And it turns out that there was basically a Soviet‐style kind of economy going on, where different projects were assigned priority numbers by the government and were supposed to go through official channels to procure, because there just weren’t enough electronic components to go around.
One of the things I was surprised to see that even involved innovation, they had the find just the right kind, was wire. Early in the project, they found the kind of wire they needed somewhere in MIT, but no one knew where it came from. So this is in the archives, a letter they taped a piece of wire to, sent it out to suppliers and said, “Do you make this wire? Can you help us get some?”
And we talk in the book about some of the other challenges. The power supplies turned out to be something that almost killed the project. No one thinks about power supplies as this great technological innovation, but it turned out they need to generate 78 different voltage levels, and the company they ordered it from turned out to be a fly by night company that just completely couldn’t do what it had promised.
Precision resistors. That was somewhere where the Dean came in very useful. I’ve got all this correspondence with the military procurement where they’re trying to explain they need these resistors and the government guy is not understanding what they mean. Fortunately, the Dean of the Moore School was also the founder of the company that made them, and is still the Director, so I think they were able to go through backchannels on that one. And that kind of work was essential to make it work.
The other thing people forget is that the computer actually has to be built. Walter Isaacson, it’s clear from his text, really has no idea what engineers do, has no idea that they are not in fact building the machine themselves. Engineers, they design things. Who builds it?
It turns out that by the end of 1944, there were seven design engineers. There were also mechanical design and drafting groups, model making teams. There were defined procedures for when design had been signed off and could be moved from one of those stages to the next one.
But the production team was the equivalent of thirty‐four full‐time workers. So the largest part of the ENIAC team by far were the people that were actually building the thing. And it’s interesting they’ve been forgotten by history, because although their job titles were wiremen, technicians, and assemblers, being a business historian I looked up the accounting records, and sometimes they spell out the payroll. You suddenly see all these women’s names like Ruth, Jane, Alice, Dorothy, Caroline, Eleanor showing up.
So when I dug through it— You may have heard of the women of ENIAC, the six operators. But it turns out before they were ever hired in 1944… And all we could really do for them was make them a literal footnote in history. We could find the names of almost fifty women. And those are just the ones with given first names. There are a bunch more that I’m sure were there, but they only have initials so we don’t know if they were men or women. In 1944 alone. And I as I say, I wish we could do more for them, but at least they got a footnote.
Another interesting angle of it. If you’ve ever worked on a grant to support a project, I think you can probably identify with this. The work that as the end of the war was looming, and there were special contract provisions that would let wartime contracts be cancelled when the war stopped. The work that Goldstine was doing spinning to his bosses how it was coming.
So there was about eighteen months where ENIAC was consistently three months from being finished. In May 1944, it was going to be relieved by October 1. In August, it would be “virtually completed” by the end of 1944. In September, work was done while it was “on the fairways.” In December, they were “in the throes of completing the production within the next two months.” But somehow by May 1945, they were still “on the home stretch” and testing was [inaudible] to start “about two weeks from now.” And testing of the full machine really only began in December, although there was unit testing before that.
Anyway, it finally came together. There the launch day. Basically the military official and some sponsors meeting with a couple of the senior people involved with the team. Good job. They had a nice dinner, filet mignon or broiled steak. Desserts; fancy cakes, which I guess…I think desserts maybe have got fancier since then.
I [inaudible] some great publicity work. Who thinks about the PR side of it? But Goldstine had been working very hard for a long time to spin this to the press, to get the embargoed press releases ready. They actually did an earlier demo just for journalists on February 1, so that the machine was on the front page of The New York Times the morning before the evening when it was dedicated, which is great PR work, and may contribute to the fact that ENIAC became so famous and well‐known down to this day. Front page of the times, that’s not bad at all.
As they started to get the thing ready, they needed to have some people to work the thing. I mean, it’s an automatic computer, but there’s still an awful lot of labor involved. They hired six women who’d previously been doing the calculations manually or with other kinds of equipment. So they thought the expertise that’s needed is to understand the calculations. If you can do it with the old technology, we can train you to do it with the new technology.
Their duties included configuring and wiring units from paper plans; helping to diagnose and correct problems; feeding cards in and out of ENIAC—I’ll say more about that in a second); working with the punch card equipment; and working with the scientific users, the physicists and engineers who had jobs to run, to help devise the setups that would it.
There’s a picture here of it in operation. One that people don’t appreciate is ENIAC actually had a remote control on a wire that could start and stop it. That’s what’s being held in Arthur Burk’s hand right here. So there would be several people working the machine basically constantly when it was in operation.
It also worked alongside with punch card machines, because the only input and output the ENIAC had was a punch card reader and a punch card punch. So any information came in as these holes on a card, encoding decimal numbers. It needed to work together with a sorter, a collator, a punch, and a tabulator, existing kinds of punch card machines, to do anything useful. To get the data ready, to get the data out. And in the more complicated kind of jobs, they really had to do a lot of work with different [runs?]
This goes with the job on the poster, the Monte Carlo calculation. You see here a lot of steps are being handled automatically by the program inside ENIAC. But there’s also a lot of steps that require the women to physically work the cards, to sort decks, to add some cards, remove some cards, run them through, tabulate them, get them ready, put them back in for the next step.
This is one of the most complicated jobs ever run on the ENIAC, the first numerical weather simulation. You’ll see here, this column are the ENIAC operations, but they’re doing punch card operations that some of them are very complicated to prepare and sort these output decks from one step to be ready to turn into the input decks for the next step. So it took them twenty‐four hours to run a simulation that would calculate twenty‐four hours’ worth of weather. And pretty much all that time was spent doing things with punch cards.
ENIAC as a Material Space
There’s also an interest in ENIAC as a material space. When it’s moved to BRL, they are basically building the first ever computer data center. And there’s other kinds of work and innovation involved with that that no one thinks about.
At the Moore School, conditions were, to say the least, not very good. There were floods in October and December , and on December 25, Mauchly doesn’t go home until 3AM and according to the log book, he left behind “five men still working, mopping water and emptying buckets with catch drips,” which must’ve been a great Christmas for everybody.
On the other hand, in October the thing caught fire, and fortunately they’d engineered a shutdown to the blower fans that ventilated it, otherwise the fire would’ve spread and destroyed the whole machine. As it was, they lost one panel and had to make an insurance claim.
The move to Aberdeen, there’s all kind of stuff in the files about how they did it. I’d assumed that military trucks would kind of swarm up and soldiers would run out… But what they actually did was hire a civilian company and make a hole in the wall to winch it out through.
And for the new space, they had to make architectural plans to install the equipment. So we see a lot of the front of ENIAC. This is the back of ENIAC, and you need a space between that and the real wall so you can get in and figure out what vacuum tube has gone wrong and change it. They had to make the ventilation system, and these are all contracted to different kinds of engineering companies. They had to design the test room. The electrical service. They had to put in a 150 kilowatt electrical service.
And a suspended ceiling. That is something we take for granted now. It was very cutting edge in those days, and they weren’t quite sure if they wanted to spend the money on it. They were like, “Well, it would be nice but it’s kind of a luxury…” So in the end they only fitted it after ENIAC had already been there for a year, when they thought, “Yeah, we’re getting so many people coming to look at this. We need to make it look nice.”
As a showpiece it was very successful. There’s President Truman visiting. Even before ENIAC was finished, there were so many people coming through that that Ordnance Department, the officials in the Pentagon sent a letter to the Moore School, “Stop showing people around.” Like, let’s get this thing finished. Even with it was technically secret. After it was publicly unveiled, they were getting delegations through several times a week to look at the machine.
On the other hand, it wasn’t working very well. The conventional story is ENIAC resumed operation in July 1947 and worked around the clock forever, until it was decommissioned. That’s literally what Wikipedia says. In reality, at the end of that year, six months after they first tried turning it back on, it was getting two hours of work done a week. All the rest of the time was spent either trying to make it do things or fixing problems.
Audience member: Here it says “mechanical brain,” and it says “mathematical,” but the electronic phrasing—and Dianne Martin had commented strongly about that image‐shaping of what—
Haigh: Yeah. The brain thing has been misunderstood in retrospect. John von Neumann and some of the other people involved with the project were very much into cybernetics. And the whole idea of cybernetics is basically people and machines do the same thing. There’s kind of a common language, a common mathematical description that works on both sides. Now, part of that is yeah, humans can have brains, machines’ control systems can be brains, too. That sounds weird to us now because that part of cybernetics didn’t stick.
But there’s something else von Neumann did, which doesn’t seem weird at all. He talked about computer memory. At that point, it would’ve been equally weird to describe a machine as remembering something. But that vocabulary stuck and we’ve got no problem thinking of RAM chips as memory, even though the brain metaphor, which is essentially the same metaphor, didn’t stick, and now seems really weird and kind of cranky. So that’s a little interesting example of history in action. We talk about that in the book.
Now, Frank Grubbs, this was a great little story. He was a PhD student when he went to do wartime work at BRL. He had to put his dissertation on hold. He finished up getting a month of time on basically the only functioning general‐purpose computer in the world to do his dissertation with. And he was able to calculate tables for statistical outliers. So that sounds good, except his month of computer time basically consisted of two eight‐hour shifts when the machine was working. And it took the first three weeks to get it to do any useful output. Intermittent power supplies dumped; They found errors in the mathematical treatment; the truncation was messing up the results. They lost time to hardware upgrades. They had to put everything on hold when the Secretary of the Army was visiting, and then they heard at lunchtime he couldn’t make it. When they did get some results, they ran it again, which was essential in those days, and they got different results. Oops.
We relied on the [inaudible] this great source, the ENIAC operations log, which had never previously been used by historians. It’s basically the diary of ENIAC, day by day in this period of operation.
One of the people who emerges as a bit of an unsung hero is Homer Spence, basically the lead hardware maintenance guys, originally assigned to ENIAC as an enlisted man in the Army and then returning as a civilian to BRL. He was with the machine for almost its whole lifetime, fixing, soldering joints, and just really understanding how the hardware worked. And thanks to that kind of effort, and obviously the tacit knowledge that the operating team was building up, it went from 25% uptime in the second quarter of ’48, to peak in the fourth quarter of 1950 at 70% uptime.
So you think of the technology as having the one day it becomes operational on, but almost two years after that, ENIAC basically was still a white elephant that did almost nothing useful. And thanks to this kind of work from the operations team that has been completely ignored, it turned into an extremely useful and practical tool.
Upgrades to ENIAC
A number of upgrades were made. ENIAC was kind of literally made and remade as a hardware artifact. One of the interesting things that this poster goes with and Mark is going to very quickly click through some slides for you with is that it was completely changed to a new programming method in March 1948. And that became what this flow diagram here captures, the design work done for what was the first modern computer program ever run on any machine ever. By modern program we mean something that expresses coded instructions with operation codes and arguments that are stored in addressable memory. So you can do jumps and conditional branches and that kind of thing.
So I’m going to switch over to you Mark to just show them— He’s going to impress you with the inscrutable… If any of you were media archaeologists, you’re going to love this.
Mark Priestley: The really cool thing about this is that we’ve got this project we started around this program that was run in 1948, which was like, we claim the first, in some sense the first modern computer program. And the really cool thing about it is we’ve got a complete program listing for it, which one little bit of looks like this. It’s actually thirty pages long like this.
What I was going to do was show you a few pictures that illustrate the richness of the documents that illustrate how ENIAC programs were planned and written and put on the machine. So that text was the 1948 program. Before that, ENIAC programs were tables or diagrams, and they kind of looked like this.
It’s a completely different notational format. I’m not explaining what any of this stuff means. I’m just showing you the richness of the documents that we had to work with.
Haigh: Yes, if you want to understand it, buy the book. It’s a bargain.
Priestley: And then there’s a complete wiring diagram like this. This is the original ENIAC in 1943:
What these documents do is tell you how to actually set up the ENIAC to run a particular problem. It’s not really a program in the modern sense. It’s almost a wiring diagram, setting switches.
And this photograph shows you some of the 1946 famous ENIAC Women programmers putting in plugs and turning switches to set up one of those programs on the ENIAC, to run.
That’s the only original document we found from one of the ENIAC programmers Douglas Hartree, a British mathematician. That’s what the notation had evolved to by 1946. And that tells you how to set up the ENIAC for his particular problem.
Then as ENIAC was being developed in the mid‐40s, of course, the EDVAC got developed and computer programming took a linguistic turn, largely due to the fact of John von Neumann during the famous “First Draft of a Report on the EDVAC” came up with the first thing that we would recognize as an order code, a machine programming linguistic coded instruction.
Haigh: And we have a whole chapter on that report. Where it came from, what it actually said. It’s very frequently cited and very little understood.
Priestley: So, what happened in 1947 was that the ENIAC team took these ideas and with John von Neumann said, “Okay, basically what we’re going to do is convert the ENIAC into a machine that runs like one of these new von Neumann architecture EDVAC machines.” And the linguistic turn, mid‐1947 they were coming up with planning order codes for the ENIAC which they were describing as “ order vocabularies.” So you know, machine code, the orders are…it’s a complete turnaround in the ideas about how you program machines.
So at the end of ’47, beginning of ’48, ENIAC is set up to run this code, and these are old‐style ENIAC diagrams telling you how to set up an interpreter for the new code.
The actual program that I showed you, there’s a column of two digits, which is the only thing that was set up on the ENIAC. The rest of it is all meant for human reading. This document is not just a code listing, it’s actually a complete working document written by humans, meant for humans to read and understand. One of the other bits of information on this diagram which is interesting is these figures in the left‐hand margin which are cross‐references to the flow diagram, which we have on the poster. And everyone’s familiar with flow diagrams. The story goes that they were invented by von Neumann and Goldstine in 1947.
But the general idea of using a directed graph to show a computation was in widespread use in the ENIAC project even before this happened. So this is a very messy directed graph by John Mauchly designing some aspect of the ENIAC. There’s a tidier version from Douglas Hartree in ’46, describing the structure of an ENIAC computation as a directed graph in what they call the master‐programmer diagram.
There’s the first official flow diagram from John von Neumann’s 1947 report, and then these flow diagram evolve into the one that’s on the poster, which is the flow diagram for the March 1947 program which was the first machine code modern program to run.
Haigh: Not that we care about that.
Priestley: Not that we care about that. [crosstalk]
Haigh: We’re above all these firsts. Just, if any of you happen to care about that at all… The first computer program has been a completely forgotten thing. We couldn’t be able to stop you.
Priestley: Slightly more legibly, a re‐engineered flow diagram in the style as the original one for the actual code that we have. I’m only putting that up here so you can get an idea of the complexity of the program. This is not a 10‐line program that adds two numbers or prints out a table of squares. This is a major, 800 instruction program with nested loops and branching statements with subroutines doing a complicated Monte Carlo nuclear diffusion simulation. The first program ever run is a big, complex, difficult program.
The other thing on the listing that I wanted to draw attention to very briefly is all the stuff on the right. This is Klára von Neumann, the author of this program, going through step by step, working out what the program does, doing a kind of dry run by hand of the program as part of the testing process, partly with numbers, partly with mathematical notations.
The richness of the documentation we have is such that we can reproduce step by step execution of this Monte Carlo program on an ENIAC emulator, running the interpreter, running the code. And if you look, the numbers there are the same as the numbers on the listing that I showed you a moment ago.
So looking at this one document of program code, that’s three aspects of it. But there’s an awful lot more you can say about this. It is a program which runs a Monte Carlo simulation of chain [reactions in nuclear material]. The first Monte Carlo program, it’s running a big application. How did it do it? It’s a large complex program, including a subroutine. The first subroutine to generate pseudo‐random numbers. It’s just an extraordinarily rich program. The whole ENIAC project has just revealed such an extraordinarily rich amount of documentation, and it’s been a real eye‐opener, actually.
Haigh: Yes. I want to stress we have in the book a chapter on the conversion, two chapters on the Monte Carlo. This is by far the best‐preserved program, best‐documented, and I think the most complex surviving program from the 1940s. So anyone who is interested in software studies or code studies from a historical kind of perspective, Mark is the one who really delved in‐depth on that, and it’s really a quite remarkable accomplishment.
Another interesting little historical thing, when ENIAC moved on to BRL, not all of the operators went with it. One of them, Jean Bartik, was hired under a subcontract to stay on Penn campus at the Moore School and head a group of people to develop programs for ENIAC. So this, I think, was the first time that anyone had been hired specifically to program, the first time a contract had ever been given specifically and exclusively for programming rather than say for computer development or computer operation. And that in a way is the beginning of programming as an occupation.
In terms of the malleability of the hardware, we talk about a lot of the little changes and adjustments they made. One of the most impressive was fitting a core memory unit. It’s one of the first core memory units to be used anywhere. Core memory was the standard memory technology from the mid to late 50s, really into the early 70s, for computing. There was actually interesting materiality of that. When core memory production ran, it was being hand‐woven by women in India.
Data Processing Operations Work in the 1950s & 60s
One of the things that you can see the history of beginning here is the history of something that’s been almost exclusively ignored, which is the operations work of computing. So Eckert and Mauchly themselves in fact leave Penn, found the company that becomes UNIVAC, and start the computer to business. I love these businesspeople here, inside the vacuum tube.
And as much as this is an [i‐school?], I’m very interested in where this whole kind of rhetoric of information comes from and how it’s constructed to make an area of professional expertise. And you’ll notice here a tiny little thing. No one was calling this information technology at that point. They didn’t have all this kind of information rhetoric. And so they were trying [inaudible] was a “fact‐troller,” which is kind of the same thing, but somehow it doesn’t roll off the tongue quite so easily.
In some of my earliest work, “The Chromium‐Plated Tabulator”, I talk about this initial period of adoption. The remarkable thing is that by the late 50s, at which point basically no computer operations were actually paying for themselves for business administrative purposes, there’s nevertheless several thousand companies that have installed computers So they really balloon in a huge kind of way.
Data processing is what corporate computing departments used to be called. Now what’s the data processing workforce in 1971? Again, we kind of think of everything in terms of the history of men doing programming. But we see almost a third of the whole workforce, the biggest job category, was women doing key punch work. Basically data entry onto punch cards. One of the things that ENIAC operators were doing.
25% is computer operations. Working the hardware, loading and unloading tapes, etc. Some of the work that the ENIAC operators were doing. Only 17% of people are called programmers, and another 11% are called analysts/programmers. So that’s under a third of people in the data processing department are doing programming work, even though that’s the only kind of work that tends to get remembered in terms of computing applications.
And of of course what we think of now as programming work is a piece of what the ENIAC operators were doing, but it wasn’t the only thing that they were doing. So what’s interesting to me in wrapping this up is some bigger points about the historical memory here, and how it comes to be that the ENIAC operators are both famous, and famous as the first computer programmers.
So there’s definitely a tragic underrepresentation of women in IT in general and computer science in particular. And it seems like the best idea people have had to tackle this is to find some women to be historical figureheads, to say to girls, “Hey look, they did this. You can do it, too.” Ada Lovelace has a day. Grace Hopper has a celebration of women in computing. And the women of ENIAC have increasingly become the third leg of this tripod, as the first programmers and as proof that women can program.
We talk in the book a little bit about how that happened historically. Until the 90s, they really were completely forgotten. There was a great article by W Barkley Fritz, who worked on ENIAC himself later on, where he pulled together fragments of memoir and was in contact with all the women and got them to write about their own experiences.
Kathryn Kleinman has worked for a very long time to make a film, and her efforts to publicize the film and publicize the women did a lot to bring them to broader attention, especially into a Wall Street Journal column in 1996. And there’s a classic history of technology paper by Jennifer Light, “When Computers Were Women” that did a lot also in academic circles to draw attention to what they had been doing.
But I have some worries about how narrowly this concept of the women of ENIAC is being described now. Their names are now etched onto this thing at Penn. I think it’s just been put up. And the women of ENIAC is saying to mean exclusively the first six operators. Not the dozens of women who actually built ENIAC. Or Adele Goldstine, who was working from the beginning of the project; wrote the manual, trained the other women in how to carry out computations. It’s very controversial whether she also trained them how to set up ENIAC. And was involved in recruiting women to do the firing table computations. Or Klára von Neumann, who did the
[The Isaacson quotes are cited are cited on the ENIAC in Action web site’s “ENIAC Errors in Isaacson’s The Innovators” page.]
…I showed you minutes ago is being done by women. But the women are doing key punch work and operations. And it’s not some great feminist breakthrough to celebrate women only for programming and to say that we have no interest in celebrating the kind of work that was typically or more representatively done by women, because that work is not worth remembering. That is not any kind of feminist position. This has been pointed out by Wendy Hui Kyong Chun, who wrote
reclaiming these women as the first programmers…glosses over the hierarchies…among operators, coders, and analysts.
Wendy Hui Kyong Chun, Programmed Visions p.34
And this is something we very much see in our analysis of it.
So to wrap up, there’s a kind of increasing loss of awareness of materiality and work in computing, in the age of the cloud. The cloud metaphor hides from view the actual physical infrastructure and challenges of computing. And I think the same in a very similar way, that historically this focus on genius, conceptual breakthrough, and programming has hidden the historical reality of early computing as this kind of very material, very labor, very specific kind of activity.
Now, everyone loves innovation. It’s science, progress, the future. I mean, Yahoo is buying you food, what’s not to like about that? So making that kind of alliance with the Silicon Valley billionaire version of innovation as Isaacson does and backwardly projects into the past is clearly instrumentally a very savvy thing to do. But it leaves history in trouble, because history by definition is about the past, and I could go on forever about how history of [?] might not find a place in the [?] world. But it’s very revealing that the famous Silicon Valley capitalist Vinod Khosla just wrote
If subjects like history and literature are focused on too early, it is easy for someone not to learn to think for themselves and not to question assumptions, conclusions, and expert philosophies. This can do a lot of damage.
Vinod Khosla, “Is majoring in liberal arts a mistake for students?”
Now, in response to that kind of thing, my friend and successor as chair of the SIGCIS group, Andy Russell, who’s worked on the history of Internet infrastructure, said that what we need to do instead is to have a project “The Maintainers: How a Group of Bureaucrats, Standards Engineers, and Introverts Made Digital Infrastructures That Kind of Work of Most of the Time.” So that’s his history of the Internet, having done the historical work to see what actually happened, and we have really I think a parallel kind of understanding of ENIAC.
So, I think history matters, even though IT is always about the future and no one wants to believe that history matters. And there’s more to history than the firsts and lone geniuses. The Imitation Game is terrible. Successful IT innovation has always depended on execution, operations, logistics, and doing those little things like the wire.
So what’s our kind of wrapping up lesson about what this shows us about the work of innovation that we see from the work of ENIAC. Well, trying to sum up what was happening seventy years ago, I think I would say ENIAC is the story of smart (to to very smart), hardworking (to obsessive), flawed, men and women who came together to do many kinds of work more or less collaboratively.
And if you want to think about what happens next, things get really really ugly, and you talk about the decades‐long legal battles that followed the couple of years of very successful collaboration. They were in the right places at the right time, supported by bigger institutions. I mean, the Army was giving them money. They had the local resources to draw on. They were able to collaborate with Bell Labs to get the relays that they needed, with the Dean to get the resistors they needed. This was a story basically of a successful kind of bureaucratic institution pulling things together to make something happen, as much as it’s a story of individual genius.
They did their jobs, I think, well enough. Not everyone has to be a genius. And even without superpowers, they still changed the world. All of them. Even the secretary, and the draughtswoman, and the wiremen, whose names are forgotten.
Audience 1: In the last twenty or so years, we've realized that software development works better as an iterative process rather than a sort of waterfall one. You mentioned about the problems that they had with ENIAC that required them to rebuild the thing constantly. Would you say from your studies of this thing that development itself, whether it's hardware or software, is always an iterative process?
Thomas Haigh: Uh…yes. And our poster, you'll see…the really cool thing is this flow diagram. We had space for one whole flow diagram, but we thought one whole flow diagram won't tell the story of this problem. So we start out with John von Neumann's plan of computation that was intended for the original programming mode, and was actually essentially smaller in scope. Then we have the first full flow diagram in John von Neumann's handwriting.
Then we actually talk in the book about a succession of draft flow diagrams, and we actually manage to capture that process where they're finding idioms that we take for granted, like using a loop to iterate through a lookup table. They're actually discovering that, and it's so cool to see people discovering this for what may be the first time, in the different drafts of the flow diagram.
And then we have later flow diagrams, and we have program code. We actually have basically annotated reproductions of many of this things on our project web site. And then here's the report summing it up. So we felt enormously privileged that this was so well documented that we could actually get inside and basically see this first iteration through the software development life cycle.
Mark Priestley: And you can see many of the subsequent iterations on this code diagram. There are red corrections where they've gone back and corrected some of the code. There are insertions where they've kind of—because this was like a [?] program which ran for like six different problems. So they have special code for some of the problems. You're absolutely right. And one of the cool things about this thing is the programs are set up with switches on the ENIAC, so they couldn't keep a permanent record of it. So the hand-written paper thing was the permanent record of the program. And because of that kind of glitch in technology, all the iterative development process is here in this one document. It's kind of beautiful.
Haigh: And what was different about software in those days (and by the way, the word software didn't exist at that point), it was not about abstraction. Because they have to be so close to the hardware. They have a very definite mathematical appreciation of what's going on. But they also have to be incredibly aware of the realities of the hardware that they're dealing with. And we kind of see that in the process, too.
Although there is the interesting sense in which, after the conversion in 1948, ENIAC hardware is only ever running one program. And the program is an interpreter that reads instructions one at a time from the changeable lookup memory on the function table. So that you could say is a virtual machine. You could also call it microcoding. But from a computer architecture viewpoint, it's fascinating to see those practices emerging so early.
Audience 2: Thank you. Love the materiality of the presentation, too. It's just so cool to see all the little bits and pieces. I was wondering if you could talk a bit more about the divisions within the gendered division of labor that you kind of ended on. Like, who were the women doing programming work versus operations work. What were educational backgrounds? For whom was it a career versus a one-time thing, or that kind of stuff.
Haigh: Yeah. Well, programming work and operations work, at least in the original year of operation at the Moore School, were the same women. And they're remembered only as programmers. They did all the operations work for all the problems, and working the machine required at least two people hands-on constantly.
They also helped… In some cases they gave assistance, in some cases I think they took the lead, in developing the configurations for the ten or so jobs that were in the Moore School. Some of them, people just turned up with everything planned out. In other cases, I think they gave a lot of assistance to people who knew what they wanted to do mathematically but didn't know how to configure ENIAC.
So the point is, in those days, and we have a nice quote from Adele Goldstine… Is it in the manual, Mark? Where is Goldstine describing the work of the operator in a way that is grouping together stuff that we would think of as programming and really quite high-level work, with stuff that we would think of as being very kind of blue collar work. At that point, those are seen as tasks that all go together. So that separation takes place later.
Priestley: Yeah. These women were hired as operators, but within about six months they were the machine experts. So a scientist like Hartree comes in with a problem. He kind of roughs it in as the algorithm. He writes out that program I showed you, and he makes some mistakes, if you read through it. He's misunderstood some aspects of the ENIAC. So presumably that gets corrected, and then in the acknowledgements of the paper he then publishes, he acknowledges Kay McNulty, the operator who helped him.
It was a whole list of things, running the machine, setting up the machine, helping him plan the computation. They kind of evolved as really complex, multi-faceted job descriptions.
Priestley: —doesn't kind of correspond to later terminology at all.
Haigh: And so they absolutely deserve to be remembered. But the interesting thing is computer science has been interested in only remembering them as programmers, not as operators. And no one has had any interest in remembering the women who actually built the thing.
Matthew Kirschenbaum: Question for Mark, actually. So we're looking at the document here, and can you just… Where do you start, as a media archaeologist? What is your Rosetta Stone? How do you actually go about understanding what we're looking at?
Priestley: In this case, we started out with a flow diagram. So the starting place was the flow diagram. And we also had a large document they'd written which summarized the behavior of the program.
Kirschenbaum: So you had documentation.
Priestley: There was a flow diagram, there was documentation which described both, and it cross-referenced the flow diagram and the code. Armed with that, we could then go through the code and literally a line-by-line annotation of what every line of the code did.
Haigh: I just want to show you a few of the things we've put online that you can see for yourselves. We've got the original diagrams in 1943 for the trajectory computations. There's a myth that these were developed very shortly before the public demonstration in '46, but a great deal of the preparatory work completed very early and shaped the design of the machine.
We've got different versions of the design for the conversion. And the first step in understanding those instructions would be to know what the instruction set is, and we've reproduced the technical report that describes that.
We've also reproduced the program code, and we've reproduced the flow diagram. So if any of you want to try this at home, basically all the key materials are now online. And we would like to thank John von Neumann's daughter Marina, who gave us permission to reproduce those materials from her father's papers at the Library of Congress.
Audience 3: My question was wondering if you looked also on how people at that time were describing work in general. Not by computers, but by say an army of people. If you're going to build a pyramid, you're also going to have loops like, a pile of bricks, and have one person come and pick it up until it's over. So there must have been other people in other domains that were not computers that were describing work in some workflow fashion, and some instructions.
Haigh: Well, sure. That's basically the history of management. I mean, there's Taylor and Gilbreth. That's in some ways where the basic ideas of management are coming from. By this point we start to get into the whole thought experiments and human relations era. It's kind of on a cusp. But what's happening in labor that's very important there, obviously, is The New Deal, the CIO, labor unions, and we're more or less up to Taft-Hartley. (You see, I'm also a labor historian.)
So it's kind of a period where you could say that conceptions of work are in flux. A big thing, obviously, is is this like Rosie the Riveter? Are women only doing this work because it's wartime? Or are they doing it because there's a precedent for women doing this kind of work? And if you think, as some people have done, of this being programming and an unprecedented thing, you can't answer that question.
But that's not how they thought of it. They thought of it as being women operating machines. So, women had been operating the differential analyzer. Women had been operating calculating machines. And women had been doing the calculations by hand. And it turns out that while some areas like physics and engineering were extremely hostile to women, women did relatively well in mathematics, particularly in applied mathematics, which not coincidentally was the lowest-paid part of mathematics. And particularly within applied mathematics, doing the grunt work of computations, which was the lowest status of work. But at this point, women were actually getting PhDs in mathematics, particularly in applied mathematics.
So I think one of the things we try and do in the book is situate this not as the magical start point of programming, but as a continuation of an earlier trajectory of female labor within applied mathematics, which I think is the specific context in which it makes most sense to consider it.
Likewise the women building the machine. On the one hand, they might have got men to do it if the men weren't all doing the war. One the other hand, women were working in radio factories, and women were working within the Bell system to produce equipment.
And one of the things that labor historians know is that the construction of what's low- and high-skilled work is completely subjective, and that any work that women do tends to be seen as low-skill. So you say, well they can do that because they have such great little fingers, or something. And this other work men can do because they have skill. And I think that kind of work with doing the wiring and so on (although unfortunately we have no documents that prove this) to the extent to which it was a continuation of labor practice in those industries, it would be based around the idea that women had the kind of delicate hands needed to do the work, and also you didn't have to pay them very well.
Priestly: I'll just make one very brief comment about materiality, because this slide got missed. The point where the abstract digital machine code, the two-digit machine operations meet the metal of the ENIAC is on these tables here. This is the ENIAC's old function tables. And the program was actually set on these things by turning these switches, and that's the point where the abstract Von Neumann machine meets the metal of the ENIAC.
Haigh: And if any of you are old enough to have used a computer where you'd debug with switches on a front panel, you'll appreciate that with the ENIAC all the program and all the data was immediately apparent with its own switches. Plus, you had lights on each accumulator that would show you the contents of every digit of writable electronic storage. So when the machine was working, actually, it must've been very easy to debug. And if you wanted to change a program when it was running, you'd just turn the switches.
Event listing at the MITH web site, with summary, bios, and complete slides.