|
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 |
|