Apollo Guidance Computer History Project

Third conference

November 30, 2001

What made Apollo a success?

DAVID MINDELL:  It may be that one way to start off the discussion for the afternoon is our question, which is simply, you know, what to you guys is the-- What are the really significant things here that we ought to be looking at? Either because they were-- Had a long-term influence or because they were something that was uniquely difficult, a problem that was solved in this case or you were mentioning a network of people from continuing in through other projects and other engineering cultures, is a really important part of it.

So in the sense-- We want to get a sense for what you guys forty years later find important about this particular project and what, if you were reading a history of it, you think ought to at least be mentioned if not explored deeper.

CLINE FRASIER: This has to do with the switch from single layers in the computer design to multi-layer boards. We at NASA were required to come up and negotiate the contract with MIT or go through the budget and figure out what they would be allowed to spend money on.

And in the spring of whatever year it was, I was a part of the team going through all this stuff. One of the line items in the budget for a considerable amount of money was work on multi-layer boards. This is something that had apparently been going on for a while, and it was at the stage where the block two computer had gone through class A release. So it was known to work, the drawings were class A released. So my question was since we already decided on using signal layers in the current CDU, why are we bothering to spend any money on multi-layer boards? I never got any kind of a satisfactory answer and being under pressure to keep the budget down, that got lined out. So there was no money authorized to spend on multi-layer boards.

That was in the early spring, I think. And then in August, I believe, there was a meeting up here at MIT - Hugh Brady was there, some other people from AC, probably some Raytheon folks and certainly MIT folks. And one of the things that came out at that meeting was "Oh, by the way guys, the computer won’t work." This was at a time when we were supposed to deliver a flight-configured computer to Grumman in December to go on the flight table for them to verify the control system stuff. And knowing how these things go, if it wasn’t delivered, Grumman was going to then blame any schedule slip on the guidance system.

So what the other thing that gets said at the meeting was, "Well, gee, we didn’t really stop working on those multi-layer boards and we have-- The logic is all in the boards." And so at that point, we decided to switch to multi-layer boards and to keep the signal layers for the computer that went to Grumman by doubling up the insulation in the signal layers which will reduce the capacitance. And keeping the computer tray open because on a flight table, didn’t matter whether the tray was closed or not.

So it was that sequence of events. It doesn’t conflict with what you said, Dave. And the other piece of that was Dick Battin and crew were convinced that we’d never go to the moon with a block two computer. It would be a block three system. So the next problem was that we discovered we had delivered the open computer to Grumman in December along with the IMU and everything. Oh, by the way, there was no software to turn the system on.

I think I must have gotten on my hands and knees to Dick Battin and said, "Even if it's not going to go to the moon, and even if Grumman is not going to be ready for it," because MIT had spies at Grumman, and I knew they won’t even have the wiring in the room until February, "will you please turn on the program so that we can just turn the thing on so we can say that we delivered?"

And one of the things that's done for me over the years, that and one other thing, is to remember that you don’t want to be too harsh about just shutting some of these things off because they save your tail.

DAVE HANLEY: Yes, but Eldon had it backed up. (laughter)

CLINE FRASIER: I don’t know who paid for those boards in that six-month intervening time and I don’t really care.

DAVE BATES: It was a long time ago.

CLINE FRASIER: As I say, nor do I care. (laughter)

DAVID MINDELL: My question really is what are the major themes, what are the things that really stand out?  What really in the end made it successful technologically? What were the really significant things, which are often things that people don't really expect?

BARD TURNER: I think Ed Duggan and I are probably closer to it-- Not only is it the continuity of the people, which we’ve already talked about, but the continuity of some of the basic aspects of the design concepts which started from Polaris. Even though it went from discrete components to something totally different, there were a lot of similarities and a lot learned from that evolution and how to partition, for example, logic. You can start reducing, for example, the number of wires, whatever the wires are, by putting some thought into functionally grouping gates that, you know, talk to each other. Also, how big is a separable item? In other words, I mean, the first welded discreet component computer was totally welded. I mean, the whole shooting match. You couldn’t take it apart, it was a book shape, and it worked.

ED DUGGAN: You could replace modules.

BARD TURNER: That's right. Well, could you have done that in the book?

ED DUGGAN: No.

BARD TURNER: That was one extreme. What was eventually the design, it went on through Polaris, was replaceable modules. Another thing which was learned was to try to make everything alike, physically alike, even from the individual components up to the modules themselves so that when they hit a production line, for example, whoever’s working on them, it doesn’t matter what specifically they do. They all look alike. So that's one thing. Another one was being able to change the function of look-alike modules based on where they’re plugged in. In other words, essentially do a pin-program type of organization where you then, because of back wiring, you make the same basic functional module do different functions in different places. And that again was a thing learned from Polaris. But the only one in Polaris that did that was the memory. But if it was done at all, and that was one of the things carried in to Apollo because in that one, it was organized by bit rather than let's say you had adders in one group and so forth, like that. There was a module called bit module, which there were 16 of them, or 14. And that was a good way to split them up.

ELDON HALL: No, there were 8 actually in Block 2. Block one had 16.

BARD TURNER: Doesn’t matter. The basic idea was to do something like that.

ELDON HALL: Standard Modules.

BARD TURNER: Yes, standard modules. And of course, that was an advantage not only physically but they look the same. So when these similar modules get to the lineup at Raytheon, they could be built with the same tooling, and same operators.

ELDON HALL: This is standardization. That was the one key issue that I used to present to Charles Frick justifying integrated circuits, because in the old version with the transistor kind of logic, everything was different. There wasn’t any commonality at all, and there was no way of getting it in that kind of circuit. With the integrated circuits, you could do it.

BARD TURNER: Right. Even though there were basically three input NOR gates, you could have a fan in capability just by taking a bunch of them together and opening up a cluster resistor or whatever was necessary. You could do that with the back part.

JACK POUNDSTONE: I’d like to address that. Obviously, the key technological issue was integrated circuits, as everybody has said. If we were stuck with core transistors, the computer never would have fit, even if they could have worked. But I think the other key technology that made the thing a success was Eldon’s determination that we were going to use a fixed memory, which ended up being the so-called poor relative . The industry was going the other way at the time, Bill Gates was getting started and programs were stored in some sort of an erasable memory form. I know when I went around the country to talk to people, they said, "We have this thing called core rope memory," they just laughed and said there was no way that could be done, because programmers will never stop changing their code. Well, the core rope memories had two features that were very good for the program. First, they had ultra-reliability. There’s no way that any erasable memory could ever be as reliable a thing called core rope. And the second was the discipline it forced on these software people, because when they were told that today is the day you release the program for Mission so and so, you had to send those cards or tapes or whatever it was to Raytheon to make that physical thing that was called a program. That that’s going to go down to the Cape, where we integrate it, as I recall it. There will be no more changes.

DAVID MINDELL: The programs were actually manufactured?

JACK POUNDSTONE: And that put some discipline into software people. At that time, they never had any discipline. They don’t today. Well, you know, when you use PROMs, you’ve got the same problems. But we didn’t have PROMs.

DAVE HANLEY: There was a constraint. There was an intellectual anathema. They just didn't want to hear this at all.

ELDON HALL: Even within Draper Lab. I was fighting with them all the time.

JACK POUNDSTONE: But the outside world thought we were absolutely crazy, and I will give Eldon the credit. He withstood an awful lot of criticism for that.

ED DUGGAN: Yes, but they spent too much money by that time. (laughter)

CLINE FRASIER: I didn’t know enough to think one way or another at that time. Well, there was a time I probably thought was not the right way to go, and there was a time I really appreciated it.

JACK POUNDSTONE: But look at the precedents. I mean, Minuteman I had a drum, right?

DAVE BATES: Didn’t Minuteman III have a drum?

ELDON HALL: No.

JACK POUNDSTONE: Probably not even Minuteman II. We had already gone through this on Polaris with the wired program. But the program was 16 words or something? I mean, it was ridiculously small.

ELDON HALL: Sixteen words of memory, yes. Mark II was 12 words of memory.

JACK POUNDSTONE: But anyway, the idea of having a large, fixed memory was just unheard of. I think that was one of the keys to making this program a success.

DAVE BATES: What was the total amount of memory at the end, was only what?

ELDON HALL: Thirty-six thousand. 16-bit memory. I saw an interesting cartoon a few years back. This kid was sitting or standing on the descent stage of the LM, looking at the other descent stage, probably in a museum. And he said, "That computer in there has 64 Mb of ram. That won’t even run Windows 98." (laughter)

ED DUGGAN: That's quite true. It probably saved the program.

ELDON HALL: That’s right. It saved the program. If it had had 64 Mb of ram, we’d never gotten there.

DAVID MINDELL: How about management? Was there a formal practice of systems engineering going on? NASA was very into systems engineering.

JACK POUNDSTONE: No, NASA didn’t have one either.

DAVE BATES: Let me just say this. Coming from von Braun with that team concept that they had there, I saw the same team concept here. When you saw the oneness of purpose of what these guys wanted to do, it was a team concept, okay? Of people working together to achieve that one goal. I mean, you’ve been talking about the technology and that, of course, is extremely important. But they needed as loose a situation as they had so that they could have a oneness of purpose and not be forced to do something by management. They were successful, you know, regardless of the obstacles, which I considered management, other people, contracts, other things of this nature, see? They had a freedom to go ahead and make these decisions, follow them through. Maybe have a lot of accidents, lot of failures. But they had the freedom to go ahead on that one purpose. The team that we had with Raytheon and with Instrumentation Laboratory at that time was second to none.

JACK POUNDSTONE: Well, we were discussing that over lunch as a matter of fact. Cline may not like to hear this, but at the time we started this program, NASA was in a state of disorganization, if you like. They had just moved to Houston and were expanding like mad. They were concentrating on Gemini, and Apollo was a side issue. And that was the most fortunate thing that ever happened because it gave us two or three years for us to figure out what needed to be done. Let’s say it was a systems engineering phase, although we didn’t really call it that in those days. It wasn’t formalized or anything like that, but it was a phase of trying to take a first crack at the thing and trying to get it down to a size you might be able to get your arms around. Now, later on, particularly when Joe Shea became the program manager, then it started to get more formal and we started getting the Cliff Duncans and Cline Frasiers and people who would come in and overview meetings and worried about money. See, in the beginning, we didn’t worry about money.

Next: Formalization of Project Management

Home: Conference 3