I recently started listening to a fantastic podcast called 13 Minutes To The Moon[0] produced by the BBC. It’s a retelling of the last 13 minutes until the Apollo 11 lander touched down. Episode 2 talked about the software and the 1202 program code. They interviewed the Guidance controller who was only 26 at the time and talked about how the average age of the flight controllers was 27. I thought that was incredible, you don’t see that much responsibility placed in such junior people anymore.
The American and Canadian military are significant examples where many organizations are 'run' by people under 30. Yes, most field-grade and general officers, and senior NCOs are over 35. But, for example, the day-to-day decisions of logistics and tactics and technological is done by people between 19 and 27, by junior enlisted and company-grade officers.
I have never had as much responsibility an operational control over my job, in both fiscal and mission terms, as I had between the ages of 19 and 23 while in the military.
There are a couple of counter examples, particularly in New Space startups. At 26, I was a Mission Director (SpaceX's equivalent to a NASA Flight Director) for Dragon re-entry and landing.
As the old Apollo-generation engineers start to retire in the space industry, there _is_ fresh blood coming in, and even at larger companies, I've found young folks in top positions. It's just not widely advertised.
I wonder how much of the low age is because it was a relatively new organization at the time. As a counter example, NASA's current average age is 50+ in many organizations.
It's a blessing and a curse. Aging organizations retain lots of organizational knowledge but also tend to exhibit a lot of stagnation/complacency.
Yes, the podcast attributed it to NASA being a new organization and there being nobody with experience in most of the jobs. There were aircraft engineers and a small number of rocket engineers before, but NASA needed vast numbers of new employees and for jobs like mission control that just didn't exist before.
It's a really good podcast, but I found it a bit bloated in places, I could have done without the Hans Zimmer theme, of which they are so inordinately proud.
I really loved the Hans Zimmer music too. I got pumped up every time I heard it. I felt some bloat at times when they really dug into that 1202 error. It just kept coming up again and again.
Yes - it's bloated for a reason ... all of the things they've spent long episodes on are so you know what's going on when they do the realtime recordings of cap com.
"you don’t see that much responsibility placed in such junior people anymore"
Sure you do, typically in new industries, like internet companies today, or space in the 60s.
Eventually the unicorns will be manned by aging suits, and JavaScript will be the new Cobol, and the hip young things will think vowels in names are actually kinda cool.
I'm amazed at the technical skill and knowledge he and his team has. Fabricating simulations, replacement parts, unpotting modules and repairing them, etc, etc, etc.
I thought the Xerox Alto restoration was amazing - this beats it handily.
It describes interesting questions that were faced on the project: say, how much control over a lunar module could be given to a computer system, and how much they should rely on human engagement.
I read this book a couple years ago, it’s great. In fact, I picked up the book 2nd hand with a note from the author inscribed on a cover page. Neat.
This book is especially interesting to anyone building systems where humans are required to interface with a computer on a “mission-critical” level.
It goes in-depth about the new type of electrical component-integrated circuits used in the guidance system. And more about other aspects of the navigation systems used on Apollo.
It's interesting to me that 50+ years later this debate on system control is still very much relevant to aerospace today, like the recent 737-MAX issue.
My limited understanding in a broader sense (as opposed to the specific 737-MAX case) is there is still considerable debate on who should have ultimate control (human or software) of the aircraft when making critical decisions. I remember reading an article a while back that made it seem like Boeing and Airbus were on different sides of this spectrum in basic design philosophy, but I don't know how true that is.
It's like any good technical religious debate: both sides have good points and the ideal that they're both working toward is somewhere in the middle.
Airbus has backed off trying automate everything (starting with AF 296 in 1988) and, as this MCAS debacle has demonstrated, Boeing is happy to add serious automation. The days of the "pilot's plane" are long over. Now it's ever thinnner shades of gray.
“You can’t get a degree in how to fly to the moon,” says Dana Densmore, who joined the lab in 1965 and became a control supervi-sor for the lunar-lander software. “You had to get people who know how to think, who are creative and alert. It was all in-vented on the spot.”
Kind of off topic, but for those interested, this reminded me of the public repo on github which has the original guidance computer source code for the command and lunar modules[0].
This is the best description of AGC I have seen so far, from hardware design to mission software, layer by layer: "The Ultimate Apollo Guidance Computer Talk" https://www.youtube.com/watch?v=xx7Lfh5SKUQ
If anyone wants to learn more about the Apollo Guidance Computer, this talk[1] from 34C3 will teach you everything you wanted to know and more.
The AGC had some really fascinating features for the time, including a cooperative multitasking system, interrupt driven IO, and even a virtual machine for doing linear algebra!
I knew a retired couple near where I lived growing up who, I found out later, were software programmers on the Apollo Program. Quite possibly worked in that lab. The husband passed away soon afterwards, and I never got around to asking the wife about her experiences (they both worked for the program!). But it was really cool reading about how the core software was written.
One part jumped out at me as brilliant especially for the time: when the computer was overloaded with tasks during the decent, it switched off all non-essential extras like screen displays in order to free up processing power. After that it shed even more to focus on only plotting the landing!
A few weeks back they said it was due to the delta h discrepancy, and Buzz did nothing wrong. This week they were saying that it was down to the docking rendezvous system being turned on, which had not been done before.
I don't know if they came up with new information and forget to redo that episode.
The delta-h discrepancy was a mismatch between the actual height above the moon, and what the navigation system expected, I believe Mission Control took over that.
The article mentions the overload on the computer was caused by "a mismatched power supply to a radar" triggering too many calculations. Any idea how or why the power supply was mismatched ? Luckily software saves the day but what was the root cause of the hardware fault ? Was that a case of a mismanaged change in configuration ?
If I remember correctly, two AC power sources were required to be in phase for measurements of the antenna direction to work correctly, but weren't actually specced as such, and thus not built that way, and randomly ended up so out of sync that it caused problems on that flight.
Eyles has a memoir out: info available here. (The title is "Sunburst and Luminary", which were the names for LM software builds for earth-orbit testing and lunar landings, respectively.)
> When it came to hiring women for engineering or management, NASA “had a few women, and they kept them hidden,” says Ms. Densmore. “At the lab it was very different,” and there were opportunities for women.
Quite amazing what an important role women like Margaret Hamilton played in the Apollo project, given how hard it is nowadays to get more women into engineering positions. You may remember the famous picture of Hamilton next to the stack of code she and her team wrote for Apollo: see https://en.m.wikipedia.org/wiki/Margaret_Hamilton_(software_...
“You can’t get a degree in how to fly to the moon,” says Dana Densmore, who joined the lab in 1965 and became a control supervi-sor for the lunar-lander software. “You had to get people who know how to think, who are creative and alert. It was all in-vented on the spot.”
So what was happening during Apollo 11, as I recall, was that repeated jobs to process rendezvous radar data (that of course were not really there) were scheduled because a misconfiguration of the radar switches. Thus, the core sets got filled up and a 1202 alarm was generated. The 1201 that came later in the landing was because the scheduling request that caused the actual overflow was one that had requested a VAC area.
Quite fascinating that these alarms automatically rebooted computer and picked up essential jobs exactly where they had left off.
I think bidding government contracts is a lot more complicated than just picking the cheapest option. There's a lot of other dimensions of validation that bids move through other than cost.
For something like this, I'm sure there is stringent engineering validation. I know some initial NN research was part of a larger government project of funding research around stabilizing missiles in flight for ICBMs that was not cheap.
Competitive bid doesn't have to mean lowest bidder. I've put tons of (non-government) projects out for bid because you're usually expected to do so to keep everyone relatively honest. I imagine the MIT Instrumentation Lab were the only people with the inertial guidance expertise at that time.
I was perhaps being slightly misanthropic. But the game keepers always seem to turn poacher. High ranking military bods end up with defence contractors. Financial regulators end up with working at banks (and visa versa), and politicians seem to end up getting various well paid consulting jobs. I suppose you could argue there are good reasons for it, I cant believe on some level these public servants aren't thinking of their career after retirement.
It depends on the contract. Some contracts do go to the lowest bidder (the technical term that the contracting folks use is something like "lowest bid meeting technical requirements"). For those sorts of bids, it's extra important that the requirements that the government puts out are well written and thorough.
Some procurements use the "best value" criteria. I think these contracts are more likely to be protested and have lawsuits filed by the losers. It's easy to say "I deserve this contract because $2 billion < $3 billion". Best value can be a bit more subjective.
Neat story but is the software really hidden? I feel like I have heard this story many times. It was one of the many feats of the Apollo program, I don't think I would consider it hidden.
As a casual space program buff, I thought the same. But I think most people do not realize how sophisticated this early computer and software were, and how important to the mission. The article emphasizes the well-calculated trust that the engineers and astronauts put into this first computer-controlled spaceflight operation.
