Apollo Guidance Computer Activities

AGC - Conference 2: Different programming styles

Apollo Guidance Computer History Project

Second conference

September 14, 2001

 

Different Programming Styles

SLAVA GEROVITCH: Was there much interaction in small groups while working on those programs? Did you have mostly one program, one programmer, or several programmers working on one program? How did knowledge circulate within and among those groups?

MARGARET HAMILTON: Maybe four or five [programmers] in each sub-functional area. A functional area such as the onboard flight software would have many sub functional groups.

FRED MARTIN: You had different areas. If somebody was working a navigation module, they probably did not have too much contact with some people who were working in powered flight. So they were worried about star sightings and co-variants matrices and things having to do with navigation computation. And somebody else was worrying about auto pilots and how they were going to fire engines and so on. They were aware of each other. But there may not be very strong interfaces between them.

These two groups, I would say, you might have a powered flight group of maybe six people and a navigation group of some other number like that. And you had people who were testing and you had people who were writing specs. So I would say you had a lot of programming groups. So when you add it up, you get to the numbers we're talking about. But each group was a somewhat contained group.

JIM MILLER: There was a parallel group of analysis people that were designing algorithms, and testing them, and so forth. They weren't really writing AGC software.

ALEX KOSMALA: I was going to make that comment. Because programmer was not a job description. Some people programmed and did analysis. And some people only did analysis. Somebody did all the work in MAC, this analytical programming language we had. I got the brunt of that because I remember, in trying to put this first flight program, of which I was the inaugural rope mother, together, I had to interface with these groups and make each group's stuff meet the stuff of the next.

I remember putting together the launch people stuff, which was just plain monitoring the boosters and tracking vehicle position and velocity, with the powered flight people's stuff which actually took over control of the mission at that point. Then it went into this mid-course thing where some of these star sighting people who were wacko analysts worked. I didn't understand what or how they did this -- I still to this day don't. Theirs was a whole different real-time regime. Because ten minutes was a short time to these guys. Whereas one second was a lot to the powered flight people.

Then, I survived going through that midcourse stuff. Got all their stuff straight. Was able then to power up Dan and Ray's entry program. And all the glue that I held this thing together with actually worked!

But there were a lot of different programming styles and conventions that you had to straighten out. For example, these guys expected the delta V but were getting it in the wrong units and scaling. This kind of thing. So putting these cells together was an integration job. We didn't integrate from the beginning. It was not one programming exercise for the whole mission. There were these separate analytical groups. Some needed programming help, some didn't. Different styles, no standards. All that received a lot more discipline and method later in the Apollo program.

FRED MARTIN: It's surprising we didn't have more interface-type errors. Because we had no standards. We had no programming standards. Each group or each little entity would have a style. I think when we got into project management, I did try, to some extent, to get some standardization. But it was hard. I think people used different expressions for constants in their programs.

JIM MILLER: But don't forget Don Bowler and what he did with ICDs. If we hadn't had a function like that with all of the specs from all of those other vendors as well as our own, we would have really been up a creek. That was absolutely essential.

ALEX KOSMALA: Big Don. Another guy I remember, even bigger, Peter Peck who instituted control over revisions and stuff.

__: He started it early. When he did it all alone.

ALEX KOSMALA: But this kind of organization and process control came out of nowhere. Peter thought this needed to be done. And started doing it. There was no, "you are the configuration manager." Peter started that kind of stuff. He'd come and argue with you. You couldn't put changes in that revision!

MARGARET HAMILTON: You don't want him to sit on you.

ALEX KOSMALA: But he invented that in the course of the work.

JIM MILLER: There certainly were integration problems outside our building. I think that our experiences within the building, and we were all within the building (which wasn't that big a building) were relatively well controlled. But some of the interface problems we had that were experienced between our stuff and the other people's stuff and between various other people's stuff. I remember, for example (was it 501, Dan, or 502?), where there was an engine failure and the booster software (nothing to do with us) shut down another engine thinking that it was the one that had failed. So it was short two engines out of five.

DAN LICKLY: Right. We ended up in Oregon. They were supposed to do a translunar injection. But because of the failure, they didn't have an S4B left or whatever it was. Instead of on a trajectory headed towards the translunar, we ended up either in orbit or an elliptical thing. So instead of doing a burn to knock us out of a translunar trajectory, we burned first to put us in. Then we turned around and knocked us out.

JIM MILLER: That was one example of one of these integration problems that woke up a lot of people. I think the accident on the pad was probably the single biggest disaster that woke people up; it stopped the project for a year and a half or so. Investigations were done and Block II was hustled into place.

Relations with Grumman


site last updated 12-08-2002 by Alexander Brown