Apollo Guidance Computer History Project

Second conference

September 14, 2001

Organization of the AGC Project

RAMON ALONSO: I'd like to add something to what Herb did that relates to the quote that you couldn't do this project today. At the time the Apollo computer first became available, there was an interim need to have something that could show that it worked. Not that it did the job. That this computer was alive. Herb programmed a little game which would be completely primitive by today's standards but was a little version of pong in which the ball bounced all over the place.

It was after doing that and then all the work that came after that Herb-- I heard Herb one day 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. What I think, in terms of why the project was done, I think the genius was in the partitioning of the project. There were several pieces. One is that we had a clearer goal. The other having an institution that was already talented. You can't do that. You're not going to go anywhere.

But then, the fact that the job was broken up so that the people could 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 single characteristics of the project.

I've been in many projects since then. Everybody here has too. I think that those projects that failed almost always had enormous bureaucracies of cross-checking that just didn't work. In other words, the partitioning was wrong.

SLAVA GEROVITCH: Where do you think that partitioning came from? Was it someone's decision or did this idea come from somewhere?

RAMON ALONSO: Generally, 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 initial platform group. Then there were the single conditionings. Then the optics group. Then the computer group which was kind of a foreign object in the lab, as I recall, for many years.   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 re-entry. And there was going to be an abort. All these things were partitioned. Davey Hoag was the person who just felt that this was way the world should be. So I think that it requires an architecting visionary on that.

JIM MILLER: A space flight consists of periods of thrust and activity separated by long periods of just tracking where you are flying to. So some of the partitioning just came from the separation by periods of inactive flight.

DAN LICKLY: I have I think two things. One, the overall speed. I think you've got to look there-- It was a totally different era. It sort of had followed not that long after World War II and it still had the spirit of whatever you've got to do, you've got to do it quick and done. Because there's pressure. In 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.

After Sputnik, we were in another mode of moving that way. Some of us had worked with Davey Hoag on the Polaris. 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-- Imagine sitting down now and saying to somebody, go. And saying, building a submarine and having it out there in 18 months. You couldn't do the paperwork in 18 months. But those guys really, really moved.

They took a submarine that existed and split it in two and redid-- 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. We had Davey Hoag to lead us, who is 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 Davey said last time was August 8, 1961 was in Washington when they awarded it. Some of us were there then. But 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. Built it in late 1961.

But there's really two distinct phases with different objectives and organization. First is the engineering phase that lasted two to four or five years, depending on what part. That's when you had powered flight, rendezvous. I was in the re-entry. Something else. LM later. But I don't know that it started that way. You guys were doing the simulator. Who else? There was about five or six groups. But it was definitely engineering organized to different parts of it. And Dick Battin was the guy that ran all of it. But we were all involved. He didn't really run it. He just nodded.

ALEX KOSMALA: He was a real hands-off manager. Just a guru in his corner office.

DAN LICKLY: Very smart. In his corner and smoke his pipe and nodded.

ALEX KOSMALA: Everybody thought he was just writing a book. But by golly, he knew exactly what was going on. And he didn't interfere. To me, that is one of the secrets of success. Again, as I said before, it was the fewness of the people that allowed this massive project to be shoe horned into this teeny box, and work.

DAN LICKLY: Each of these engineering groups was quite small. We had three or four in the re-entry. And each of these others didn't have a lot. 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. You informed them what you were doing and waited for critical comments. But you weren't ridden.

ALEX KOSMALA: I had a single point-of-contact at NASA. Tom Gibson. Remember him? The cigar chomping guy. He oversaw our work. But he didn't interfere. We told him. There were not hoards of bureaucrats who caused you to fill in forms and make briefings. We didn't have that at all. But you kept Tom happy. He kept the bureaucrats off your back and you went on with the engineering.

DAN LICKLY: Then we awoke several years later realizing we had a big programming problem. So we switched from the engineering. Develop equations, make simulations, studied, developed guidance equations. We swifted 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 was all consistent for a particular flight.

You found stupid errors from engineers here and there. Like somebody for pi using 22 over 7. We kept getting errors and couldn't figure out. This guy, he was from the old school. There were subtle errors that even got to a flight. You think Earth Rate is a well-known constant, hasn't changed very much. Earth Rate is Earth Rate. For us novices, although we knew more at the time, the Earth rotates once in 24 hours. That's was 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 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. I can't remember what early flight there was.

So things did get through. But the programming effort was directly differently and organized differently. And these guys really, Margaret, Alex, Fred, all really took over in a very good way to lead all of those. Then we had to break into LM versus command module. LM engineering took a lot longer because Grumman was longer. Some of us thought we were done and they were just almost getting starting. Alan Clumpf. And then the auto pilots came along which required some more engineering.

JIM MILLER: For a long time, there was a concept 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. In fact, you actually 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 stayed the same.

DAN LICKLY: I think I'm on the only one that we flew exactly the same thing twice. I don't think there's any other. 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.

JIM MILLER: But the trouble is a lot of us were somehow fooled into believing the myth, even after we knew it really wasn't working that way. And we thought with these small groups of people we could handle it. I remember conversations in which we said, "We've got to do this with either about five people, maybe six, or we've got to do it with 150." The number we had, about 30 or 40, was going to kill us. We had to go either one way or the other. Happily we went to the 150, although it wasn't fun at the time.

DAN LICKLY: It was very difficult.

JIM MILLER: A whole new culture.

DAN LICKLY: 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.

JIM MILLER: We couldn't figure out why anybody else besides us needed to know what was in the guidance computer. Why does NASA need to know? Why do we have to publish all these documents? 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 project's big money and big pressure, and got off. One day, there was a two-day meeting at the Laboratory of about 30 people late in the Apollo project to decide whether the executive program for the shuttle computer should be interrupt-driven or schedule-driven. I'm not sure it came to a conclusion after 60 person days. But Hal said to me, "These people have just spent more man-days in that meeting than it took me to conceive of and write the entire executive for the Apollo computer."

Things just had changed by orders of magnitude. It was clear to me it wasn't going to be fun anymore to work on that sort of stuff. So I didn't.

Hugh Blair-Smith adds:

I think my experience was unique, in that that my role was always interdisciplinary, and never fitted into one box on the organization chart (assuming there ever was one). Officially, I belonged to the Digital Computing Group, a name that was already obsolete insofar as it implied a group that did the digital computing on behalf of everybody else. But what it meant then was systems programming, creating the digital infrastructure so that the IMU specialists and the guidance specialists and so on could write their application programs.

My task of designing and implementing the Yul system, with its assembling and manufacturing functions, was certainly a mainstream activity for that group. And--more or less typically of the way that group worked--I did it all by myself for eight years, except for some help from a wonderfully quick fellow named Cliff Ide with a module for the Polish-prefix interpreter code. "Specifications" consisted of a few scattered conversations with key people; in that tight little community I had no problem figuring out who was the key person for any topic.

But the process by which I got into instruction set design was so irregular as to fit into nobody’s diagrams! I give Albert Hopkins full and grateful credit for giving me a chance to bring my self-taught specialty into the Mars computer series and thus to the AGC series, and of course I should acknowledge Eldon Hall for letting that happen. My specialty was the study of what makes computers hard or easy to program in assembly language, and what makes the programs themselves more or less efficient both in use of time and use of space. The extreme constraints of a short word length and tiny operation code field only added to the challenge and thus the fun. And then when the demands of Yul System maintenance became less than full-time, I was invited to design and build Routine 29, a flight software module that would wave the LM’s Rendezvous Radar about, searching for the CSM after lunar liftoff. Also, I was among the many people hastily devising code to send up to help the Apollo 13 CM separate from the LM prior to re-entry, though a simpler non-software solution was found.

The point is that my roles, undefinable in any reasonable organization chart, were whatever the people in that tightly knit community thought I could help with. Hal Laning’s approach, that anybody who knew how to do something should be allowed to do it, ruled--even though he took himself out of the game when it seemed to grow too large. Nowhere did the dead hand of bureaucracy crush the creative and cooperative instincts, at least from where I sat.

Years later, as a hobby activity I devised an instruction set design that would do what the Space Shuttle’s General Purpose Computer (the IBM System 4-Pi Model AP-101) did, but in one-third the memory and perhaps half the time. That stayed at the hobby level because the Shuttle project had none of the flexibility of the Apollo time. NASA had made up their mind that the Shuttle computer was going to be off-the-shelf, so I knew it wasn’t worth even offering my ideas. Well, on the other hand, I did succeed in exerting one important influence on the Shuttle computer design, because what IBM sold NASA as "off-the-shelf" was in fact a box of vapor, a design concept that may have been prototyped to some degree but certainly wasn’t on any shelf. When the IBM folks presented the design, I was horrified to see that the double-precision floating divide instruction took about 50 times as long as most instructions. I told them I could write a subroutine in AP-101 instructions that would achieve double-precision division faster than their lame instruction. When I made good on this boast, IBM was shamed into going back and redesigning that instruction to take a more reasonable time. This was a great goose for the old ego, of course, but I felt that it was a good deed anyway. I had been in projects where people twisted code into pretzels to avoid doing divisions, and it ain’t pretty.

Trust in automatic systems

site last updated 12-08-2002 by Alexander Brown