Change in Culture

For the first few years of the Apollo program, IL engineers defined tasks, built prototypes, conducted experiments, and did much of the creative, exciting part of flying to the moon. In the middle of 1966, however, everything changed. At the end of the Gemini program, Lickly recalled, ''NASA descended on us.''

''We awoke several years later realizing we had a big programming problem ...and now we needed a new organization,'' Martin recalled. ''Instead of having 30 people, we needed 200 people.. .we needed all this documentation. And we needed all these review meetings. And we needed all this NASA supervision.'' The whole team became ''professionalized,'' Martin said. ''We were going to have something called project managers.'' At NASA, Martin saw enormous management charts laid out on the walls, and ''some contractor who would come up everyday with his blue tape or red tape or yellow tape and mark where the schedules were____It was magnificent to see it.''

Martin seriously tried to adopt NASA's management methods but the increased oversight brought a new era to the lab, and ''much less fun for a lot of people.'' NASA's managerial sophistication impressed a younger Ray Alonso differently: it was the first time he'd seen an electrically powered eraser.68

Part of the reason the programming proved so difficult was that writing serious, detailed requirements for the software amounted to defining the mission. Hoag felt that not all of NASA's criticism was fair, as the programming was often hamstrung by lack of data, specifications, or procedures from elsewhere in the program. ''It has turned out that MIT has had to do a large measure of the mission planning—how the test flights and lunar flights will be performed, in order to complete these tasks,'' Hoag said, and therefore the programming task ''turned out to be far greater than originally estimated.''69

NASA began considering turning creation of the actual mission programs over to one of the contractors, which would be a huge blow to the IL. Battin and Ralph Ragan successfully fought the move, and in mid-1966 NASA asked the IL to program not only the basic system, but the missions as well, a task that brought them intimately into the challenges of flight planning, including its severe time pressures. Feeling a late-Apollo budget squeeze, NASA also asked the IL to reduce its staffing and to transfer most of the less-technical work (training, ground support, etc.) to contractors.70

At this time the IL's software efforts received the attention of Bill Tindall, the most famous unknown player at NASA in the Apollo story. As part of the Mission Planning and Analysis Division (MPAD) in Houston, Tindall had been instrumental in the Mercury and Gemini programs, helping to turn the theory of orbital rendezvous into reality.71 A true space enthusiast with a talent for clear, straightforward writing, Tindall began looking at MIT's software effort in early 1966 and he didn't like what he saw. His ''Tindallgrams'' became well known within NASA for their technical insight and blunt language. Some of the earliest concerned the Apollo software effort.

Tindall started making regular trips to the IL to see what was up. At first, nobody took him seriously. Martin remembered him as ''an object of real derision____We were rolling along doing all of this fantastic work building software, doing this, doing that, when NASA sort of somehow woke up and decided that these guys were totally out of control.'' NASA's concerns: the documentation was no good. There weren't any real schedules.72 The IL group was having great fun, but was insufficiently attentive to testing. ''Testing is the name of the game when you're playing with mission safety, critical kinds of systems,'' Jack Garman remembered, but the IL folks treated it like busy work and didn't understand why they had to write up numerous different test reports for NASA.73

Tindall began a devastating series of missives in May 1966. These Tindallgrams began with the alarm: ''There are a number of us who feel that the computer programs will soon become the most pacing item for the Apollo flights.'' A strong statement. Previously, nobody had paid much attention to this novel thing called ''software,'' the pet project of a bunch of academics up in Cambridge. Now software would make or break the schedule for the firm, end-of-the-decade deadline.

Tindall studied the organization, with Battin in charge and four subunits reporting to him. Yet he still complained: ''I still do not have a clear understanding of how their work is broken out between the four units.'' Tindall had brought some NASA engineers with him who were working with IBM on the Real-Time Computer Complex (RTCC), which did the heavy number crunching at Houston, and he hoped that MIT would learn from them and adopt their management techniques. Indeed the IL began assigning a person responsible for the program for a particular flight, for managing it through the entire process from coding through manufacture and test. In typical IL style, they called this person the ''rope mother'' (though it was usually a man).

Tindall was particularly worried about bloated program size, some of it brought on by an obsession with precision by the academically oriented IL engineers: ''I am still very concerned about unnecessary sophistication in the program and the effects of this 'frosting on the cake' on schedule and [memory] storage. It is our intention to go through the entire program, eliminating as much of this sort of thing as possible. I am talking about complete routines, such as 'Computer Self-checks,' as well as little features, such as including the third and fourth harmonics of the earth's oblateness and drag in programs for the lunar mission.''74

IL engineers all remember Friday the thirteenth of May 1966, ''black Friday,'' when Tindall called everyone together to cut their favorite programs out of the software so it would fit into the limited memory. In the dry language of the official report, ''these meetings became emotional because of disagreement about what was, in fact, nonessential.''75

Two weeks later, Tindall was again writing, this time a memo titled ''Apollo spacecraft computer programs—or, a bucket of worms.'' He began, ''Well, I just got back from MIT with my weekly quota of new ulcers.'' Tindall was pleased that the rope mother for AS-204, the first manned mission, seemed to have adopted some of the IBM techniques (like a program development plan). Still, the mission was exceeding its allocated memory by as much as 500 bytes (at that time a large margin, or 2 percent). More distressing, the rope mother was trying to put together the total program without having tested all of the units individually. ''Certainly a very unsatisfactory situation,'' Tindall remarked.

He concluded that the program for AS-204 ''will be of less than desirable quality. It will not have undergone sufficient verification tests and will very likely still contain program bugs'' when it flies into space. Tindall intended to put Houston people at MIT to watch over the IL group day by day, ''with no alternative but to march along with our fingers crossed.''

Programs for the later missions, especially the Block II and manned missions, were in even worse shape. ''After recovering from our complete shock,'' about the schedule for AS-501 and AS-502, Tindall and NASA again concluded the programs would have to be ruthlessly culled and accelerated. Said Tindall: ''The program paring must be done, I feel, solely for schedule reasons, which is really kind of weird when you think about how long the programs have been under development. It will mean that we fly to the moon with a system which does not minimize fuel expenditure nor provides the close guidance tolerances which are ultimately within its capability.''76

The eternal compromises of system engineering now compelled trading weight and fuel for schedule and memory capacity. Who would have thought that a few bytes of memory could compromise the accuracy of a moon landing? Who could have foreseen that imperfections in the programs would consume the scarce resource of fuel— programs nobody even knew they needed when Apollo began?

Over that summer, and for months afterward, the bad news continued to flow. There were not enough programmers, so the IL began hiring contractors. The number of people working on Apollo software began to rise steeply in the middle of 1966 and continued until shortly before the nearly Apollo 11 launch. Costs for the second half of 1966 were double those of the first half of the year, nearly a million dollars per month.77 The IL did not have enough computers to support simulation on anything but the next mission, putting the efforts behind for subsequent flights. Rope mothers were assigned for each mission, and they each had to assemble a series of subroutines from the programming groups into working mission program. ''In most cases,'' Lickly recalled, ''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.''78

Despite the software turmoil, in August 1966 the unmanned, suborbital AS-202 flight tested a Saturn IB with a Block I command module aboard, the first flight of the Apollo guidance and navigation system. This was a high lob intended to give the CM heat shield a reentry test. It carried a Block I spacecraft and computer, with a ''mission programmer,'' a set of relays to mimic the actions of an astronaut. The craft flew on all-inertial navigation for an hour and a half. The guidance system performed successfully, monitoring the launch, aligning the command module for firing of the service module's engine, and guiding the command module on its reentry trajectory.79

After this success, in September 1966 George Low wrote to Robert Gilruth of his concern that MIT was ''very far behind in the preparation of software . . . the general conclusion is that we must put the MIT programming and scheduling on a more business like basis.''80 The program for the first manned mission, AS-204, caused the most serious problem. The crew had recommended a number of software changes to improve the flexibility of the data in their displays, but they would have to be left out because of schedule and testing requirements. Programs for at least the first four missions were late, too large, not reliably tested, and full of bugs. IBM and NASA programmers had developed ambitious plans for the ground computers to interact with the spacecraft, but these would have to go ''straight in the trash can,'' in Low's words, because the flight vehicles would not be prepared to provide them adequate data. The IL was pushed to release a program that Kosmala remembered ''was just so lousy, so full of bugs.''

On a fateful January day in 1967, that program, and the three astronauts who were scheduled to fly it, burned up on the launch pad.

Telescopes Mastery

Telescopes Mastery

Through this ebook, you are going to learn what you will need to know all about the telescopes that can provide a fun and rewarding hobby for you and your family!

Get My Free Ebook


Post a comment