Apollo Guidance Computer Project - MIT Conference Series, Part 2

[MUSIC PLAYING]

GEROVITCH: So I think everybody is here, so I thought maybe we could start. My name is Slava Gerovitch. And my email is on the board, which conveniently has my first name on it.

Professor David [? Mandel, ?] who is the principal investigator on this project, is speaking today on the National Public Radio on Science Friday program. So I'm not sure if he'll be here. [? Sandy ?] [? Brown ?] who is a research assistant, and who has been in contact with all of you, is currently in New Zealand. And he couldn't make it back because of the recent tragic events. So I think these events kind of make us think that maybe we should appreciate every day of our lives that we have, and try to do as much work as we can today.

I will say a few words about the overall project for the sake of Jim Miller and [? Eric ?] [? Taylor, ?] who were not here at the first meeting. The project is called History of Recent Science and Technology on the Web, and its goal is to develop some tools that would enable veteran scientists and engineers to participate in writing the history of their particular disciplines or projects. So our role as historians here is just be your helpers, to offer you some tools and to listen to you what you would like to have in terms of support and logistics that would allow you to contribute to writing history.

There are different formats for using the web in this way. Some people prefer using web forums or email lists, things like that. David [? Mandel ?] has suggested that we would have these live meetings, where people would exchange their memories and discuss some of the historical issues. Then we would have these meetings transcribed and put transcripts on the web, where everybody could read them and comment on them.

We also are planning to put-- or actually are already doing it-- to put some archival documents up on the web, where you could read it and, again, you could write comments on particular documents, on parts of it, which will also be posted on the web. So people after that could come and see your comments and the original document, and maybe write some other comments.

So these are the kind of things that we're thinking about. If you would think that some other forms, like a discussion list, would be helpful, please let us know, and we'll try that. I don't know if anybody of you took a look at the website, which is hrst.mit.edu. And it stands for history of recent science and technology. Doesn't have any www.

So this is the overall project, which includes five subprojects, one of which is Apollo guidance computer, one is molecular evolution theory, one is bioinformatics, and a couple of others. In different fields, people try different approaches. We'll see what works in our case.

So far, we've had one meeting last month. And we already have a transcript of it. And as far as I know, it's been circulated somewhat, and people wrote some corrections. And we are planning to put it up on the web shortly, within the next couple of weeks, where you will all be able to see it and comment on it.

I should mention that this website is kind of working tool. So it has two layers on it. One is public, what everybody can see, and one is a working area where only members of our group can see. And so when you put your comment on the web, only members for our group would be able to see it at the moment, so because we would like to have some kind of place where we would be able to discuss our views freely and have some debate. And then we would decide to what extent we would open it up to the public.

So at the first meeting, we generally-- I'm just saying it for the sake of Jim Miller and [? Eric ?] [? Taylor, ?] who were not there-- we generally had an introduction when people talk a little bit about their role in the development of software for the Apollo guidance computer. And some of the general topics came up. What I would like generally to do is to focus on a few important issues in this project that really made that project so salient and significant, issues that, first of all, allow that enormous enterprise to be accomplished successfully.

So as Fred Martin, I think, put it last time, if we had to do this program today in the manner in which programs are done today, I don't think the program could have ever be done. I don't think that the amount of paper generated, the meetings, the views, the number of people involved, I don't think the program could have ever gotten off the ground. So that's a very interesting comment that suggests that the way the project was done back in the '60s was kind of unique. And we've tried to recreate that uniqueness. And for the reason, your own reminiscences as participants are invaluable. That's something that documents cannot tell us.

So I would ask you to bring up as much as you can these elements of uniqueness, of something that distinguish that particular project and you work on it from other things. If you could compare it particularly with other things that you encountered in other times and other places, organizations, and to draw explicit comparisons, that would help us, too, to determine what distinguishing features that would be particularly helpful.

Another thing that we would like to do is to avoid writing kind of linear history, when basically what we often can see is just a line of decisions. First there is this, then that, then this, then that. [? And then it's ?] [? success. ?] There are always some points where different decisions could be made. There were debates when, you know, there were some roads not taken. At some places, they had to go back and take the other road, and then go back. So we'd like to recreate that rather complex road map instead of just a sequence of solutions that we eventually found their way in the eventual product.

So we'd like to have that sense of debate, of controversy, what exactly was the points of contention at different points of the project? Which design decisions or organizational decisions were particularly important and debated at the time, so that history would be alive rather than a sequence of facts.

A few things that came up in terms of topics that we discussed last time, or the issue of the degree to which the automatic and manual systems must be combined in the guidance of a spacecraft. And as far as I can see in this discussion, mostly the issue of trust in the electronic equipment came up. And the astronauts didn't really trust it.

So the automatic side had to be justified somehow. While in the Soviet program, curiously-- and I should mention that I am actually working on the Russian side of this story-- in the Soviet program, the issue was to what extent we can trust the humans, the opposite issue. So somehow, the Soviets had a greater belief in automatic systems, in their reliability, and they thought that the humans were the weakest link.

So I'd like to kind of frame that issue a little bit around this question. Maybe these issues came up in your project, as well, but you simply didn't mention it. So that would be interesting. Another thing is man-machine interface, to what extent the astronauts had an input into the way they wanted to interact with the computer, to what extent computer designers had their say.

The role of warning systems, to what extent computer was allowed to let the astronaut knows that something that astronaut is doing is not really right. The issue of memory constraints and speed constraints that really put a limit on these kind of backup and warning systems. Also, series of implementation meetings was mentioned in the issue of disciplining the software program, introducing all sorts of measures that kind of streamlined that process and made it manageable from the NASA point of view. And I would like to-- maybe if you could say a few words about the way that was done, how it was accepted, what consequence did it have, and a little bit more detail on that.

And lastly, the question of openness of the whole project. Again, there is a startling contrast with the Soviet program, which, as you know, was all classified and run under the military umbrella, while the Apollo project was open. And some of the participants in the last meeting stressed that it had a very important role. And I really want to push you a little bit on that, and see whether this openness actually maybe posed some problems for you, in terms of interacting with military people. Maybe military people didn't want to tell you something because they knew that your project was open, or-- I'm just speculating about that, maybe it wasn't a problem at all. So maybe you could say a few words about that.

So today's meeting, I would suggest to start by asking Jim Miller and [? Eric ?] [? Taylor, ?] who were not here the first time--

PRESENTER 7: [? I ?] [? was ?] [? here. ?] [INAUDIBLE] Alex [INAUDIBLE].

GEROVITCH: Oh, Alex [INAUDIBLE], sorry. To introduce themselves and to talk a little bit about your role in the Apollo guidance computer story. And then we would go around the table and have people talking about the issues. Start with Alex?

PRESENTER: OK. I think I started the-- I joined the lab in '63.

PRESENTER: For the second.

PRESENTER: Hm?

PRESENTER: For the second time.

PRESENTER 5: For the second time. Dan was one who winkled me out of England to come over at the start of the Apollo program. I came as a physics graduate. I knew nothing about computers, analog or digital. I knew nothing about programming.

PRESENTER: I knew that.

[LAUGHTER]

PRESENTER 5: And one of my observations actually has to do with that because one of the successes here-- I mean, I know when Margaret joined, she didn't know anything about inertial navigation systems-- I hope I'm not putting words in your mouth-- and yet, we grew this knowledge to the extent that we needed to understand it, to control the right programs that control it. To me, that was always amazing, that so few people, relatively inexperienced in the subject that we were dealing, they were just smart people, managed to acquire enough information from a vast array of resources around us in the lab to not be blocked by a wall of ignorance.

I can't move because I don't know. You went and found out. You talked to people. And there weren't very many people that you needed to do that with. To me, one of the strengths of that program was the few people that were working. And we always came to the conclusion-- and Dan and I talked about this in the early days, that the optimum size of a software group producing complicated software like this was about five or six, because during some of the stressful period where we were really churning stuff out, there were little knots of five or six people that really put the foundations to this.

One of my roles when I began to feel my way around that I can remember-- and my memory is really starting to come apart at the edges-- was to integrate some of these areas. There was a launch area, there was a reentry area [? on the dam, ?] there was a powered flight area, who were investigating some of the technical problems in these various areas. I had to stick these together in order to achieve our first guided flight, which I still have pictures and [? stuff of ?] which we knew as Apollo [? 202 ?] is to manufacture the glue and just make stuff up that integrated the astronauts' actions, the powered flight equations, track the launch, which we didn't control. So when the time we took over, we knew where we were and how fast we were going [INAUDIBLE] then we took over. The midcourse stuff, which was a whole other ball game, which I knew absolute nothing of. And even at the end of the program, I really didn't understand it very well.

So my role was to knit some of these pieces together. And my memory is dim, but it was a heck of a lot of hard work. Long hours. Stuff didn't work. Stuff we made up as we went along didn't work. But in the end, it all did work. If I remember rightly, that first flight landed remarkably close to its objective in the Pacific.

PRESENTER: Being late late for lunch, because I wouldn't let you go you when you were dying of hunger. You remember a few of those, right?

PRESENTER 5: I can ramble on, but I think to me the amazing thing about this, looking back, was the quality of the people, the [INAUDIBLE] of the people, the immense support that you got from all the resources that were arrayed around you. The openness, I guess, is what you were referring to before. We ourselves, at least that's what I felt, were the only blocks, because of ignorance. But we overcame that as we went along, and we made it work.

I'll just shut up at that point. I'd like to hear what some of the other people [INAUDIBLE].

PRESENTER: You'll get another chance.

GEROVITCH: All right. [? Jim? ?]

PRESENTER 1: Not sure exactly how much of what to cover, but let me cover some things briefly about how I got there and what I did. I evaded the draft during the Korean War by going off to graduate school and staying in college. Got a master's degree in electrical engineering. And that was as long as I could postpone being in the service.

And I entered the service in 1956, the Air Force, and was assigned to a place called Cape "Cana-vare-al," or something I had never heard of. John [? Daley, ?] who read the news on TV, hadn't heard of it either, and that's how he pronounced it. But within a week or two of being there, I was out at the Cape, and watched the Redstone launched at night. And I was completely hooked into the idea of rocketry and guiding the things.

And I stayed in the service a couple of years, and came up to MIT to get a doctorate in program-- Doc Draper-- called instrumentation, which was a combination of academic disciplines, multi-departmental. I started writing code for computers in '57 or something. We had a digital computer down there.

And eventually, I got into programming it for whatever reason. And writing my doctoral thesis, I got into both celestial mechanics-- because I wrote on guidance of a one-pound thrust rocket vehicle from Earth orbit to lunar orbit. 1,000-pound vehicle with a one-pound engine, if I recall. It takes a long time to build up the energy you need to get up to the moon. But in the process, I learned a lot about celestial mechanics and trajectories, and about writing code for computers.

And I really have to say that the computer part of it appealed to me more than any of the other parts, although I liked celestial mechanics. But when I finished my work, Doc Draper had, through his incredible influence, landed a sole-source contract at the laboratory-- instrumentation lab, where I was based-- to do the Apollo guidance system in late '61.

And with Bob [? Stern, ?] Dick [? Batten, ?] and Hal Laning, we were a group of what I think was called Advanced Guidance or something to work the Apollo problem. There were other people in the [? Polaris ?] side that were busy, as well. But we started without really having any contact with those folks.

I worked on trajectories and trying to figure out abort trajectories and so forth. But pretty soon-- maybe that was later, but Hal Laning had written an executive and an interpreter for a computer, which was being proposed to be the onboard computer for Apollo, which was a computer that had originally been intended to fly to Mars and take one photograph, and come back and drop it somewhere where it could be retrieved. It never happened, but that computer, which was a 15-bit computer, of all things, with three bits for op code and 12 bits for address, was very nicely designed. It had eight op codes and 4K of memory, of which I think 500 words were erasable. The rest was fixed memory. These folks know more about that than I do.

But Hal had written this executive that dispatched tasks on a priority basis, and an interpreter, which was something I'd never even thought of or heard of. Hal was probably not the first to do that, but a real pioneer in a lot of ways. But he had written its code, and I started reading it and trying to make it better, which was difficult.

But it occurred to me that one of the things that we were going to need is something that simulated that computer. Because we didn't have a computer to run, and if we had, it wouldn't have been designed for debugging and so forth. So I got, eventually, into the game of writing a computer simulator for the Apollo-- for what we called then the Mars computer. And that developed, over time-- and I sort of skip around a lot-- but over time, into a full simulation of the spacecraft, [? the ?] guidance computer, all of the hardware that interacted directly with the computer, or that controlled the spacecraft, and even with the crew, including where the fixed stars were, and all the sextant operations and so forth. And ended up in the library developing a star catalog, which as far as I know, was the one that went to the moon.

Well, I don't really know. I lost track of it. But they don't change very fast, so it probably stayed the same. And the group developed into, I don't know, half a dozen people or so on different aspects of writing the simulation. And we were racing to get it ready in time for Alex's Tool [? Two ?] software. And I say Alex's because he was in charge of it, and bore the brunt of all the stress. Other folks just took life easy, and--

PRESENTER 6: Like Margaret.

PRESENTER 1: Margaret and Dan, and [INAUDIBLE]. But trying to keep up with their needs to do the simulation. We had, at that time, moved from 650 powerhouse [? of the ?] instrumentation lab up to a Honeywell machine, which was designed to do insurance programming, I think, and had lots of tape drives. And fun machine, but wasn't quite fast enough, so we eventually got a faster one, and then we moved onto IBM machines.

PRESENTER 5: Is that the one with [INAUDIBLE] on it?

[INAUDIBLE]

PRESENTER 1: I remember one day, we had two [? 370 ?] 75's, just about the world's fastest commercially-available machines, other than maybe some other-- [? I'd seen ?] more [? crazy ?] machines. And we had fixed it up so each one had two big [? 23 ?] 14 arrays. 23 [? 14 ?] was a big disk drive, which was about the footprint of this table. It had eight multi-platter disks in it. Nine, actually, because one would fail or something. I guess it was for loading up another on one while the other ones were in use.

And as I recall, we had two of those connected to each machine. And because of cable restrictions and distance of the machines, we had a fifth one that was halfway between the two machines, with a cable running from each, so we had a shared disk. And I remember standing there thinking, we have a gigabyte of storage on this machine-- well, almost-- between these machines. And I thought that was-- I mean, it was, at the time, absolutely mind-boggling. Not nearly as mind-boggling as what's happened since then.

[LAUGHTER]

PRESENTER: You should point out, a megabyte on the 75 cost about $1 million. [INAUDIBLE]

PRESENTER 1: Well, the machine that I ordered-- the 75 that I initially ordered had 1/2 a megabyte of memory. And little did I know-- and it [? had ?] four 23 [? 11's ?] because the 23 [? 14's ?] weren't available. I've forgotten how small the 23 11's were.

PRESENTER 5: I [? think ?] the 28 megabytes.

PRESENTER 1: They were small.

PRESENTER 5: Yeah.

PRESENTER 1: And the operating system used up, I think, all of the space, and all of the memory, leaving no space for anything else. But memory was so expensive. We just-- well, we had to buy-- we went up to a whole megabyte. I remember, living in the Netherlands, bought a megabyte of memory for my AT that I had bought. And rode home from the electronics store with a megabyte of memory in my pocket on my bicycle. And I thought, gee, things have really progressed. Now my 60-gigabyte disk that I have on my machine at home fits on my shirt pocket. Just can't believe what's happened.

And it is very difficult for me, having even been there-- and I think for people who weren't there, almost impossible-- to imagine the difficulties that people dealing with a machine with a 15-bit word and lots of restrictions upon expanding it-- even though the technology was available, the reliability requirements prevented much happening that would take advantage of what could have been done. Trying to squeeze enough software in there to fly to the moon and back into what became, I think, 36 K-words of fixed memory, and 1K of erasable memory.

PRESENTER 6: 2K.

PRESENTER 1: 2K, yeah, and 1K accessible. Right. And squeezing that out of 3-bit op code and 12-bit address took some funny shenanigans, which caused a lot of debugging activity. But I don't think anybody can imagine the kinds of problems that were faced trying to squeeze a huge amount of software into that tiny machine, which really was small.

After getting the simulation group going-- and there are lots of war stories about that, probably of little interest to most and known by the folks here-- I foolishly accepted the responsibility of becoming the leader of the mission program for the first lunar module. This was after the Apollo fire, and long hiatus of flights during which time everybody moved to the block two stuff.

And I remember a long, long time, it seemed that Alex was sweating and working on the [? 202 ?] software. The 204 software had never flew. It was going to fly in that [INAUDIBLE] which the three astronauts died on the [? pad. ?] But I went to Alex, and I don't know if Alex remembers this, but I remember it. I've told a lot of people.

I said, Alex, I don't know anything about the mission software. I've been doing the simulation and trajectories, and I know all that stuff. Cool. But I don't know anything about the mission program. What do I do? What did you do?

He says, well, anytime somebody comes to you and asks you what they should do, make something up. And I said, you're kidding. He said, absolutely not. He said, if they come to ask you, they don't know, and they know better than anybody else. So if they don't know and you don't know, you got to make something up.

Well, he was exactly right. It worked. You just had to not get stuck on something. You just had to take a path, and not all of the things that either us made up, probably, but certainly in my case, worked. But if they didn't work, you found out about it. And then somebody would come back and say, this didn't work. What should I do you? And make up something else different. And that usually worked because then you knew. It was the seat of the pants a lot of the way. And that's probably a good place for me to shut up for now.

[INAUDIBLE]

PRESENTER: [INAUDIBLE] about 9:15.

[INAUDIBLE]

PRESENTER 2: Well, I got involved in the Apollo project by way of a backdoor. I was working for Raytheon, and attached to the instrumentation lab on the Polaris project as a resident. And shortly after that petered out a little bit, I became reattached as a resident on the Apollo program in the computer group.

And when I-- just putting things in context, I was all of three years out of school. So not what you'd call really, tremendously experienced in computer design. But got into the computer group and was doing work with Ramone and Dr. Hopkins, Dave [? Shanksy ?] to go ahead with the Morris computer.

And then, shortly after arriving, the concept of the integrated circuit arose. I remember a meeting in Elden Hall's office, where we all gathered around and tried to determine which direction the group ought to go as far as implementing either with the Morris circuit technology, the core transistor logic, or the integrated circuit approach, and all of the issues that that was going to raise. And the decision was made to go ahead with the integrated circuit approach. Of course, none of us knew what an integrated circuit was at that time.

But I ended up with the responsibility of re-implementing the Morris design in the integrated circuit world, and carried that through. It's a very interesting computer design. Many levels of interrupt. I remember tech words like pink, mink, shink, and shank--

[LAUGHTER]

--for, essentially, instantaneous reaction to requests from resolvers and sink rows, and communication links, and things like that. And a multi-structured level of interrupts and software levels of hierarchy. I also remember a fateful day in 1963, sitting in the Apollo computer lab, which was a big room, and then a little room behind it.

I was in the little room behind it with the first brass board Apollo computer prototype. I was debugging it when the word came that Kennedy was shot. That was kind of a real seminal moment. I think everybody became particularly re-energized in making this project work. And that was my role.

I did a little bit of programming, when the design was finished, to some orbital calculations. But my role was primarily in the design of the hardware.

PRESENTER 3: I'd like to add something to what Herb did, which was a quote which I think applies to the business of you could do this project today. At the time the Apollo computer first became available, there was an internal need to have something that could show that it worked. Not that it did the job, that this computer was [? alive. ?] And Herb programmed the little game, which would be completely primitive by today's standards. But it was a little version of "Pong," in which the ball bounced all over the place.

And it was after doing that, and then all the work that came after, that Herb-- I heard Herb, when they say, you can do so much with 4K and so little with 40. You know? You can do so much with five people and so little with 400 people all trying to do the same job, which I think is part of the thing.

And what I think the-- in terms of why the project can be done, I think the genius was in the partitioning of this project that [? was ?] based on several things. One is having a clear goal. The other having an institution that was already talented. [? You ?] can't do that. You're going to go anywhere.

But then, the fact that the job was broken up so that people go work, as to what they did. And didn't have to constantly cross-check everything at every second. There was plenty of that to be done. But I think that that's probably one of the [? signature ?] characteristics of that project. I've been in many projects since then-- and everybody here has, too-- and I think that those projects that fail almost always had enormous bureaucracies of cross-checking that just didn't seem-- the partitioning was wrong.

GEROVITCH: Do you think the right partitioning was achieved by intuition, or did that idea come from somewhere?

PRESENTER 3: Well, generally, somebody's-- there's got to be a combination of political and technical architecting done. I don't know if it's any one person. But I think the lab had-- first of all, the lab was divided by stovepipes. So there was the gyro group, the [? Herschel ?] platform group. Then there were the single commissionings, and then the optics group. And then the computer group, which was kind of a foreign object in the lab, as I recall, for many years.

But so that partitioning by discipline already existed. But even within that, I think once the job was done that there was going to be a mid-term guidance and a booster guidance, and a reentry. And there's going to be an abort. All these things were partitioned-- [? it's ?] probably Davie [? Hoag ?] was the person who just thought that this was the way the world should be. So I think that it requires a [? architecting ?] visionary on that.

PRESENTER 1: Our space life consists of a lot of periods of thrust and activity, followed by long periods of just tracking where you are flying to. And so some of the partitioning just came from the separation by periods of inactive flight.

GEROVITCH: Sure, sure.

PRESENTER 4: You want us to-- are you through over there? Should we all start?

PRESENTER: Sure. Now it's all yours.

PRESENTER 4: Well, I have, I think, two things. One, the overall speed, I think you got to look that it was a totally different era. It sort of had followed not that long after World War II, when it still had the spirit of whatever you got to do, you got to do it quick and done, because there's a [? per ?] pressure. And the aerospace industry, for instance, started with nothing when the-- '41. And by '45, they had built 300,000 airplanes and bombers and transports. So they had an industry that really tooled up and moved fast.

And after Sputnik, we were in another mode of moving that way. Some of us had worked with [? Davy ?] [? Hoag ?] on the Polaris, and we worked on the guidance and so forth. But those guys-- Admiral Rayburn and the special projects-- they started, said go. In 18 months, they had a submarine built and ready to take a missile by short-- I mean, imagine sitting down now and telling somebody, go, and building a submarine and having it out there in 18 months. You couldn't do the paperwork in 18 months.

But those guys really moved. I never quite understood-- well, they took a submarine that existed, and split it in two, and redid-- it took all sorts of tricks to do it. But those of us who worked on that also saw that, whatever you did, it was going to move very, very rapidly. And we had [? Davy ?] [? Hoag ?] to partition-- to lead us, who was really a genius, as far as I'm concerned. A lot of us think he's the mentor for engineering, showed us what engineering really was.

Then, when we moved to Apollo, which [? Davy ?] said-- last time was August 8, 1961. It was in Washington when they awarded it, and some of us were there then, so we were there from even the start. But it started, as Jim said. Then they started to put together teams. There was a little before, but not much. And built it in late '61.

But you got to have two-- there's really two distinct phases with different objectives and organization. First is the engineering phase that lasted, well, two to four or five years, depending on what part. And that's when you had powered flight, rendezvous. I was in the reentry. Something else. LEM later, but I don't know that it started that way.

And you guys were doing the simulator. Who else? There was about five or six groups. But it was definitely-- engineering organized different parts of it. And Dick [? Batten ?] was the guy that ran all of it. But we were all involved--

PRESENTER 5: Well, he didn't really run it.

PRESENTER 4: He didn't really run it.

[INTERPOSING VOICES]

PRESENTER 4: He presided.

PRESENTER 5: And he was real hands-off.

PRESENTER 4: Real hands-off.

PRESENTER 5: Just a guru--

PRESENTER 4: Right.

PRESENTER 5: --in his corner office.

PRESENTER 4: Very smart in his corner, and smoked his pipe and nodded.

PRESENTER 5: Everybody thought he was just writing a book, but by golly, he knew exactly what was going on. And he didn't interfere. And to me, that is one of the secrets of success. Again, as I said before, it was the fewness of the people--

PRESENTER 4: Right.

PRESENTER 5: --that allowed this massive project to be shoehorned into this teeny box, and work.

PRESENTER 4: Each of those engineering groups was quite small, as [INAUDIBLE] said. We had three or four in our entry, and each of these others didn't have a lot. And you had a free hand. NASA was very busy with a lot of other-- they had a lot of other things cooking. So we had a lot of ability. We went to these panel meetings every month or two. In my case, it was Aaron [? Cohen. ?] And a lot of other NASA that you-- you informed them what you were doing, and waited for critical comments. But you weren't ridden.

PRESENTER 5: Yeah. I had a single point of contact with NASA. Tom Gibson, remember him?

PRESENTER 4: Right.

PRESENTER 5: The cigar-chomping guy?

[INTERPOSING VOICES]

PRESENTER 5: He oversaw our work. But he didn't interfere.

PRESENTER 4: Right.

PRESENTER 5: We told him. There were not hordes of bureaucrats who caused you to fill in forms and make present [INAUDIBLE] briefings and that kind of crap. We didn't have that at all. You kept Tom happy, he kept them off your back. And you went on with the engineering.

PRESENTER 4: But then we awoke, several years later, realizing we had a big programming problem. So we switched from the engineering-- develop equations, make simulations, study, develop guidance equations. We shifted to a different mode. We had a program, [? this ?] AGC. And now, we needed a new organization, different people leading it. The organization changed entirely.

And now, it was more mission-oriented, where you integrated all the needs into-- like, he started the 202 one, and different people took over other ones, and integrated the efforts of these different groups, and really had to program it. Because in most cases, the engineers did a so-so programming job, and it had to be redone and put into a form that would [INAUDIBLE] consistent for a particular flight. And you found stupid errors from engineers here and there, like somebody, for pi, using 22 over 7.

[LAUGHTER]

We kept getting errors, and couldn't figure out. And then this guy-- I mean, he was from the old school.

[LAUGHTER]

[? Good ?] enough for--

PRESENTER 5: Good enough for a [INAUDIBLE]. Exactly.

PRESENTER 4: And there were subtle errors that even got to the flight. You think Earth rate is a well-known constant, hasn't changed very much. Earth rate is Earth rate. But for us novices, although we knew more at the time, the earth rotates once in 24 hours. And that's what the guy used on his calculation. But that isn't right. The Earth does not rotate once in 24 hours. 24 hours is when it gets back to the sun again. But if you're doing the Earth's rotation rate, it actually rotates in about 23 hours and 56 minutes, as I recall. And if you use the difference, your longitude is going to be way off, which it was. And I can't remember what early flight there was.

So things did get through. But the programming effort was directed differently and organized differently. And these guys really-- Margaret, Alex, Fred all really took over and, in a very good, delete all of those. Then we had a break into LEM versus command module. LEM engineering took a lot longer, because [? Grumman ?] was longer, they didn't know-- some of us thought we were done, and they were just almost getting started, Allen [? Klumpf. ?] And then the auto pilots came along, which required some more engineering. Anyway, I've--

PRESENTER 1: For a long time, there was a myth that was absolutely nothing more than a myth, that each mission program was a slight enhancement of the one that went before. So that all you had to do for the next one was the enhancement. The myth part was that you had to start all over again because everything was different. Somehow the hardware was different or the mission was different. There were very few things that--

PRESENTER 4: I think I'm the only one that we flew exactly the same thing twice.

[LAUGHTER]

I don't think there's any other. Maybe [INAUDIBLE]. 501 and 502 were identical because they were unmanned. There was nothing. And I think it was absolutely the same thing. But I don't think we did any others that way.

PRESENTER 1: But the trouble is a lot of us were fooled into believing the myth somehow, even after we knew it really wasn't working that way. And thought, with these small groups of people, we could handle it. I remember these talks in which we said, we got to do this with either about five people or maybe six. Or we got to do it with 150. The number we've got, which is about 30 or 40, is absolutely going to kill us if we keep on. We have to do either one way or the other. I think, happily, we went to the 150, although it wasn't fun at the time.

PRESENTER 4: No, it was very difficult.

PRESENTER 1: A whole new culture.

PRESENTER 4: Especially when you had what's-his-name from IBM's-- Brooks [? Law, ?] that adding more people to a job that's in trouble makes it later and things like that.

PRESENTER 1: We couldn't figure out why anybody else needed to know what was in the guidance computer besides us. What does NASA need to know for? Why do we have to publish all these documents? But we, of course, did have to publish all that stuff.

Speaking of the point that Fred apparently raised in the prior meeting, and that Dan touched on, I remember-- I mentioned Hal Laning, who had written the executive for the Mars computer, and who stayed involved for a while, but decided he didn't like the big money and the big pressure. Got off.

But one day, there was a meeting sort of late in the Apollo project, in which-- it was a two-day meeting at the laboratory of about 30 people to decide whether the executive program for the shuttle computer should be [? interrupt-driven ?] or schedule-driven. And I'm not sure it came to a conclusion after 60 person days.

But Hal said to me, these people have just spent more time-- more man days-- in that meeting than it took me to conceive of and write and debug the executive for the Apollo computer. I mean, things just had changed by orders of magnitude, and it was clear to me it wasn't going to be fun anymore to work on that sort of stuff, so I didn't.

PRESENTER 6: I'm very familiar with this particular issue. And I'll get into it a little bit later. It is the tail, almost, of a long story that I would categorize as almost a religious war between the synchronous executive folks and the [? interim ?] priority-driven folks. And it mushroomed in the shuttle program, and it had its roots in Apollo. And perhaps, I'll get into that a little bit later.

PRESENTER 1: You asked about trust in automatic systems. I remember-- just a short anecdote. We were visited at the laboratory one day-- and I don't remember when, but fairly early on-- by John Glenn and [? Alan ?] Shepard, and I think there was a third astronaut. I don't remember who. And it was at the time when reporters were still chasing around after the seven astronauts, and it was a big thing when the astronauts were coming.

And the laboratory was showing those folks what we were doing. And one of the things that, at the time, we kind of had the arrogance to believe we should do was to make sure that nothing could be done by mistake by the crew that would endanger them. So there were a lot of tests that said if the delta v is in the wrong direction, or this or that-- I can't remember what all the conditions were. There were lots of conditions. Then they couldn't execute the proceed order to go ahead because something was-- you know, the software thought something was wrong.

And [? Shepard, ?] with his marvelous way about words, I remember two things he said there. But this one, he said, you guys think you know more about what is going to face us during flight than we will know during the flight. He says, you're wrong. He said, take all of those inhibitions out. He said, if we want to kill ourselves, let us. It may involve saving ourselves.

Anyway, of course he was right, and I think everybody sort of woke up to that. It made the software a lot easier, too, [? because we didn't ?] have to worry about all those [? checks. ?]

[LAUGHTER]

But he was adamant about that.

PRESENTER 4: They did let him start the pre-launch program on the way--

PRESENTER 1: That's right.

[LAUGHTER]

Well, they weren't capable of perfection. They were pretty well-trained, and they certainly were motivated.

PRESENTER 4: They were very well-trained, I will say that. But they also got very tired.

PRESENTER 1: Yeah.

PRESENTER 4: I had the reentry, which is at the end of five days out there. And they swore, through all the early years, that they were going to fly it manually. And as far as I know, none of them ever touched the manual stick. I mean, they were so beat. And then, all of a sudden, you hit seven G's. I'm not sure they could even see what was going on by then. Because I mean, they didn't get any sleep out there for all that time, really, did they? I'm surprised they were as-- doing as well as they did after all that time.

PRESENTER 7: Yeah. I think [? our ?] we had a different opinion of this subject matter than the astronauts did, or at least the software group did, at the time that this took place, the pre-launch. And we talked about that the last time, when he selected pre-launch during flight. So I think there's sort of a in-between. You don't want to overdo it, but you also want to make the crucial areas, where you can't have a catastrophe.

PRESENTER 1: Shepherd, in that meeting, was responsible, I think, for the demise of another thought that we had had, which was that the computer, not being perfectly reliable, it was going to be possible to do in-flight repairs. And so there were a lot of thoughts about diagnosing what had gone wrong and changing modules and so forth. I don't know how far along that got, but [? Shepherd's ?] comment to that was, yeah, and we should all train to be brain surgeons so we can operate on each other. And I think that was about the end of the in-flight repair.

PRESENTER 6: I think there were two areas here that people are talking about that somewhat different. There was the small group, seat-of-the-pants effort that was unfettered and unhindered, for the most part, by NASA, and devoid, pretty much, of real bureaucracy. And I think that, as Dan pointed out, you had-- a lot of the fundamental engineering work was done during that period. And it was very fortunate that we were able to do it unfettered. Because I think that a lot of the fundamental issues on how to get to the moon, let's say, were solved in this period of isolation-- almost isolation [? and ?] small groups.

And these various flights that have been talked about, I think the term-- when Alex was talking, the term system mother came into my head.

PRESENTER 1: [? Rope ?] mother.

PRESENTER 7: [? Rope ?] mother.

PRESENTER 6: Rope mother.

PRESENTER 1: Yes. [INAUDIBLE]

PRESENTER 6: And this was a person who was-- the responsibility was focused upon this person for a particular flight, even though it was a relatively small group. But I think this era was-- I would say this is the pre-built [INAUDIBLE] era. And I think that, somewhere along the line, someone did some, let's say, back-of-the-envelope calculations about how many lines of code we have to do, how many person months-- how many lines of code per person month and things like that. And came up with a number of people that were just completely different than what the lab had in doing this work.

So instead of having 30 people, we needed 200 people or something like that. And not only that, but we needed all this documentation, and we needed all these review meetings, and we needed all NASA supervision, and we needed a lot of stuff.

And at that point, there was a LEM that was being split off, and we sort of became quote, unquote "professionalized," in the sense that I remember one day-- and I can remember the day very clearly. There was an evening meeting about 7:30 in the evening, with Ralph Reagan running the meeting. And the lab has been under a lot of pressure in previous weeks with respect to NASA coming down and questioning their organization, and questioning their documentation, and questioning their testing and questioning everything.

And I was told, that evening, that we're going to have a different organization and we're going to have something called Project Managers. And we didn't have any project managers. We didn't have that title, anyway, even though you might think of a [? rope ?] mother being a project manager.

And that's when I was appointed the project manager of CSM software. And another individual, George Cherry, was appointed the project manager of LEM software. And these groups now were fairly large, and NASA wanted to see formal schedules, and time to complete this module, and time to complete that module, and reporting on a monthly-- I can't even remember the schedule, what it was. But things started to build up in reviews and in paperwork, and in monitoring and so on. And I would say that that became a different era of doing work at the lab, and much less fun for a lot of people.

GEROVITCH: Excuse me. Can you put a date on that switch?

PRESENTER 4: It was after Gemini that NASA descended on us, but I don't know quite when the date was.

PRESENTER 6: Yeah. I would say-- I'm guessing, and I'm doing it on my own time schedule. I would say it's either-- it's either in the fall of [? 1960-- ?] I think it's the fall of 1966. I don't think it's into '67, But I--