As a developer, I can't imagine the type of stress when you are put in a spot to debug code live, and the outcome of that directly impacts people's lives.

Software engineering interviews: 60s: - Can you code? - No -...Good you're hired! 2019: - Do you know Javascript, C/C++, C#, HTML, CSS, NodeJS, .NET, Angular, JQuery and React? - Yes - We'll get back to you!

Just prior to the Apollo 11 launch the simulation team realized that they had never simulated approach to landing computer failures in training. Accordingly, they ran a few simulated failures with the ground control team and the back up crew. One of the failures they ran was a 1201/1202 alarm. During the simulation the ground crew mistakenly called for an abort. The simulation team explained that an abort was not required under those conditions. The ground controllers then went through all the possible error codes and noted what should be done for each code. They had that handwritten set of notes available to them during the Apollo 11 approach. When the problem occurred for real during the landing of Apollo 11 it was news to the flight crew, because the backup crew was used in the simulation. The ground controllers, however, had seen it before. If you listen carefully to the ground control loop during the actual landing of Apollo 11 you will hear one of the controllers say “that’s just like what we had”. He was referring to the alarms they had previously seen in the simulation. They knew exactly what to do: allow the crew land. The 1201/1202 alarm was caused by the computer being overloaded by the rendesvous radar which was not required for a landing. But Buzz Aldrin, who had a PhD and orbital mechanics and rendezvous, thought it would be best to leave the rendezvous radar on in case they had to abort. He reasoned that the computer would have a head start for the abort rendezvous with the command module. The checklist, however, specifically required the rendezvous radar to be off during landing to prevent this exact situation from occurring. In the documentary movie “In the Shadow of the Moon” Buzz Aldrin admits to this mistake.

From never have written a single line of code ever and interviewing for insurance jobs at 23 in 1966 to going ahead and programming the computers of Apollo 11 in just 3yrs at 26 in 1969, man this guy is a genius.

I'm amazed they hired someone who didnt code. The good old days where employers would teach you up, instead of treating you like a disposable item.

He politely didn't mention the "human error" was Buzz Aldrin. Aldrin later admitted leaving the tracking radar on. He was scared they may not be able to find Mike Collins after they left the moon, so at the last minute, he decided to leave the radar unit on, instead of follow procedure. He didn't know the computer didn't have the capacity to track the moon and Collins at the same time. Amazing that Aldrin did this... If they had aborted the mission because of the alarms, you would have to speculate that Aldrin would have never flown again. Come to think about it, he didn't.

I was always impressed by Armstrong at that critical moment being so calm. People playing him in movies usually do a poor job because they want to make him hyper and near panic for dramtic effect. I never understood that because we had actual recordings of exactly how he was. Calm as steel.

This guy is like a cross between Matt Damon and Philip Seymour Hoffman

Was bummed he didn't get the insurance job, strolled into the MIT instrumentation lab and was cold hired with no experience. I want that America back.

I received a 1202 error yesterday... after taking a closer look, I realized that I was 2 min late for lunch :)

I had an uncle who without a high school diploma or college degree designed electronic circuits that stymied engineers so much he was hired to design communication and inertial guidance circuits for Mercury, Gemini, and Apollo missions, and also on the SR-71. He was very good, but died from a heart attack about age 55.

As a programmer from 74 to 04, watching him pour over the program listing brings back great memories. A great job for this 23yr old back then.

Today, if you want to initiate an emergency call, you have to wait for the Ad to finish.

One correction: Buzz has publicly admitted that he left the rendevous radar ON while the landing was taking place. That was in direct opposition to procedure. Buzz said that he wanted the rendevous radar ON in case they had to abort the landing. The computer was thus receiving TWO radar inputs, not just the landing radar. THAT is why it went into an error state.

Android: has like 300 MB of free space Play Store: error 1202, not enough memory

State of art 36k memory on the Comp doing the most complex effort of that time! Thankx for the info. It's both humbling and imbues appreciation for all the hard work people did back than- laying the foundation stones, and then, the stepping stones for others to improve things later. Our lander just crashed on the moon 12 days ago with TB in memory and multifold of advances.

Meanwhile, I'm complaining at work about my horrific python code running too slowly when I have a million times more memory and some absurd amount more processing power to work with. Major kudos to Mr. Eyles for his amazing programming accomplishment and contribution to advancement of humankind.

I had the honor of meeting Mr. Eyles several times in the nineties. Very nice guy. It was only after meeting him a few times that someone told me he "worked on Apollo". He never brought it up. He's got a book out called "Sunburst and Luminary: An Apollo Memoir".

I didn't know a middle-aged Matt Damon use to work for NASA in the 1960s.

This does not mentions Margaret Hamilton who was the one who came up with the idea of asynchronously running the code despite of the error. She came up with that concept for fail safe which to this day is used in programming.

The scarcity of memory space forced programmers to be optimally efficient. As they said at the very end, their programming prowess is much more refined than today. Bravo to these great thinkers. USA!

I'm glad he mentioned how important this coding concept ended up being- where you have super high priority code that will always run and background that will end up being skipped (which is the end result of not running things that are not important)- I know we were using that same idea for the basic structure of our time sensitive computations to run automotive engines even 40 years after the landing. After that, computers have gotten fast cheap so that good code writing has long gone. Which is too bad (as others have posted)

How does Margaret Hamilton not even get a mention? She wrote a lot of that, she was officially the director of all 350 programmers, most reports sound like she was the only one concerned with QA, and she was the one who blew the whistle on the fact that flipping the wrong switch could crash the computer - which she discovered after she let her daughter play with the simulator and her daughter promptly crashed it. Nobody listened to her until Jim Lovell flipped the wrong switch on Apollo 8. They should make a prequel to Apollo 13 called Apollo 8: The Other Time Jim Lovell Almost Died in Space. In the case of Apollo 11 Aldrin flipped the wrong switch because a bad checklist told him to flip the wrong switch. The error code the computer gave was a warning meaning “the computer is overloaded and is prioritizing important stuff so you’re not going to die.” I think she’s been correcting people that it wasn’t the software the broke it was the software that saved them ever since a letter to the editor of some geeky magazine defending her software in 1971.

13 Minutes to the Moon Podcast did a very good break down of this error and the follow on error. A team and the controllers put together a go buy for every alarm that the computer would say and had a go no-go plan for each. It's really impressive how quick the decision was made, and how a simple error made it happen in the first place.

You can tell he's put time into providing as much honest thoughtful insight into his answers as possible. Pleasant individual.

He is also one of the unsung heroes of mankind's greatest space mission till date. 🖖✌️

Programming in those days was an incredibly detail-oriented endeavor, and required extensive knowledge in the fundamental workings of the system. Paring the code down to its absolute minimum to minimize memory requirements and optimize speed was quite a challenge. Brilliant!

What is amazing is the youth of many of those engineers. Had we maintained the momentum of the 1960s, we probably wouldn't have landed on Mars by 1980 as many thought we would (getting to Mars is a lot more problematic than we thought in 1969), but we'd probably be there by now, as well as having launched some deep space exploratory vessels as well.

This man deserves an autobiography deal!

Back in the day, programmers made efficient use of the available hardware power, unlike today's bloatware.

I can relate to this guy. I graduated college and my first job was writing reports in COBOL and our computer room took up an entire floor of the building, and each 5MB disk drive was the size of a heavy-duty washing machine. My boss, the director took me under his wing and helped me get up to speed in COBOL. Those were the days. He gave me the chance where others would not have. I eventually surpassed my colleagues and moved on to bigger and better things. That one chance gave me the opportunities I have now.

What a fascinating and illustrative story, I suspect on more levels than it first appears. And it might be a great introduction to any presentation of "the evolution of computing," at least. Many thanks to the uploader.

On the 1973, at IBM, I used to write programs using 2K of code on a /360 modelo 40.

If we are talking about "the real story" then the explanation presented in this video is wrong. The "real problem" was a design error in the way the tracking radar communicated with the computer. It did so by sending pulses. Thpose pulses were generated by the radar unit and what should have been done (but wasn't) was to phase synchronize them with the rest of the computer. As a consequence the radar flooded the computer with interrupt requests which took away to many computing cycles such that the computer could not catch up with processing them. This destroyed the carefully adjusted timing of the different tasks which where essential in performing the landing. The "operating system" figured this one out and restarted the system thereby getting rid of those computing requests (which were unnecessary at that time of landing anyway). So the point is not, that Aldrin has turned on the tracking radar. He did so, but if the interface specifications would have included a phase synchonization in the way the radar works, nothing would have happend - no error would have shown up. It was somewhat random how the exact phasing of the radar turned out to be, depending on the exact phase relation when the radar was switched on. This is why this flaw did not show up during testing. Well, one can argue that this problem would not have shown up if Aldrin had not turned on the tracking radar, but this is somewhat misleading. The problem originated in the tracking radar specificatinons itself. When Aldrin turned it on, this just brought the problem to the surface. And THIS is the real story behind the 1201 and 1202 errors (of course in a short form). Don Eyles has written a paper about it, which explains all of that in much more detail. But the way it is presened in this video is a grossly misleading. It was not Aldrins fault ("someone had accidently flipped a switch when it shouldn't have been flipped").

This guy is greater programmer than anyone exist today Thanks for sharing this great story and introducing this great hero

No mention of Margaret Hamilton, who wrote the code that saved the mission

Hal Laning was the real genius behind-the-scenes. His intuition resulted in a computer able to focus on higher priority tasks. Let there be...Executive Overflow. BRILLIANT work!

I remember seeing an interview with Buzz where he says he left the radar on. He wanted to keep track of the command module at all times in case of abort. He took the blame for leaving it on and overloading the computer.

Truly amazing story, thank you for making this documentary

I've been a computer programmer for 40 years, this guy was a pioneer

Absolutely fascinating. Thank you!

When I got a 1202 code in my truck, it was a cylinder two misfire!

Great piece of journalism. Great to hear from that dev himself

I was learning to program at that same point in time. Memory was so expensive, even on ground based computers, we had to strain to make the code as compact as possible. We used assembly code (or machine code) because compilers were not efficient at that time. Many years later when I started using "C", the compiler had been developed to be more efficient and it produced programs that were more compact than I could do with a reasonable amount of effort. Now days with cheap memory, the emphasis is on "gee whiz features" and "keen graphics" that use unlimited amounts of memory but the final result is nice. I do like the performance of modern computers.

The radar switch that caused the overload resulting in those two error codes coming up was not turned on accidentally, but on purpose, albeit differently from the standard procedure. According to Buzz Aldrin, he turned that radar on as an additional safety precaution, which him mind made sense at the time. But that action had never been planned in advance, so the computer was not ready to handle the additional task normally, hence the error messages.

I've been hearing how the apollo flight computer code is unreadable, unusable, it's lost anyway, and nothing runs it. Here's the programmer with the green bar printouts and the memory modules. And one of the flight computers was recently restored by the guys at curious marc.

In the summer of 1966 they took a random guy aged 21 with a math degree from Boston University, who was rejected a few days earlier by an insurance company, to write major parts of the needed software for the Apollo Project. This sounds rather strange to me. Summer of 1966 is rather late to start software development for the Apollo project. Someone or some group at NASA must have realized in the early sixties that they needed software.

the real story requires mention of margaret hamilton, this guy's boss, who inspired the code that gave mission controllers the confidence to continue the landing.

It actually wasn’t the first time they had seen the 1202 alarm. According to Gene Kranz’s autobiography, mission control did in fact know exactly what those codes meant. What’s amazing is how they knew them. During their last practice simulation of the lunar landing, the simulation supervisor intentionally overloaded the computers to trigger the 1202 alarm. No one in MC had ever encountered it before or even knew what it meant and couldn’t figure it out in time before landing. The result? They aborted the mission. So when the 1202 alarm went off during the real mission, they had done their homework. It paid off. Listen to the MC audio during the Apollo 11 landing when the alarm goes off and you’ll hear one of the flight controllers say “its the same one as before.”

Curious Marc needs to get in touch with this gentleman. Seeing those modules sitting there was amazing. The printout is nice as well. Now that Marc's team has the only working AGC and dsky in existence it would be great if they could collaborate and recover the data from those modules or get a perfect working memory module to use while it's on tour. Even tho the original is repaired it could fail again with no backup. Everyone that has piched in on Marc's project is being credited. This man is responsible for helping in a huge way of putting a man on the moon

Where is Jack Garman in this story? He was the only guy during the mission who knew straight away what those codes were. It was him that saved the mission.

I found this really interesting. Thanks for posting.

Very nice explanation and perspective - Thanks for posting!

SO FREAKING JEALOUS!!!!!!!!!!!!!!!!!!!!!!! Glad his name is finally known for his brilliant efforts.

When I worked, I was a hardware engineer. Over the years I have seen the capacity of RAM and ROM memories (Eprom, EEprom, Flash) grow and I have noticed that software engineers who once cared about optimizing lines of code, possibly using the Assembler language, today, with the C language, do not they care more about HW resource saving: it's not a problem anymore and they don't even think about it. However, the consequence is that systems are slower than they could be. On the contrary, the advantage is that programming is easier and faster.

This is very inspirational to me. I am a man without fancy education working in a field where most have four and even 8 year degrees and seeing what this guy accomplished off the street is very cool.

Truly the Wild West of computing, a programmer with no computer training and then working with rope core memory. Amazing.

Fascinating documentary about a fascinating subject. Thank you for this.

Don came to MIT with a Mathematics degree, so not just some guy off the street. Read about the Apollo 14 abort malfunction where Eyles wrote code while Sheppard and Mitchell were separated in the LM about to enter the PDI phase of the descent. Mitchell manually entered the changes (that would bypass the abort switch) relayed by radio as they appeared out of the Dark side of the Moon (amounting to over 80 keystrokes on the LM computer pad) just in time.

The quick fix of the code to override an abort on Apollo 14 was equally as impressive. These people were nothing short of amazing for the job they did under that kind of pressure. So proud of our people and how professionally they performed!!!

From what I remember, I thought someone had memorized all the program alarms, and knew that the 1201 and 1202 alarms were just because the computer was overloaded. That they actually were okay with the alarms, not that they were just proceeding without knowing the problem. Pretty sure they knew what it was, and then Houston took over monitoring the Delta H so the computer wouldn’t be overloaded.

It's insane to think that the computing power they used was less than the power of a smartphone.

In the late 70s/early 80s I worked on some of the very first digital electronic fuel injection systems for automotive engines. Our joke was "Do you have blood pressure ? (Or, "Can you fog this mirror ?") You're hired !" Our first EFI system for a 4 cylinder engine that actually went into production vehicles and meet emission requirements of the day, had 8K bytes of "masked" ROM (the zeros and one were set permanently in memory on the "masked" used to make the silivon die) code and about 300 bytes of RAM !! 6 months later we were at 16K bytes of "masked" ROM code and about 400 bytes of RAM. 2 years later, we were at 32K bytes of EPROM and 2K bytes of RAM.

Who are....these amazing people? No words for it.

In an interview, Buzz Aldrin said he had accidentally left that radar on. The radar was the acquisition radar to guide them to the capsule after they took off from the surface of the Moon. I always took it from what Buzz said they had used that radar when separating from the capsule and had simply forgotten to turn it off for the landing. The acquisition radar plus the ground radar were simply feeding the computer system too much information.

Love the interview with the programmer to round out and provide background information for the story. BUT, it is well known and commented on by Aldrin himself that he left the rendezvous switch on because of concerns for a quick exit (so to speak) if the landing needed to abort. Once again, I just find it incredible that a major news outlet either does not do its homework or just out and out lies.

Wonderful to highlight Some of the Very Best Unsung Heroes in the Apollo Pyramid

What I am missimg in this video is the fact, that Steve Bales and the backroom guys at MOCR have it figured out even before the mission started. In the simulations before the mission they were given the same type of alarm. When Bales called an abort, the simulation supervisors told him, that he shouldn't have done that. In reaction, Bales and his team, went over all the computer alarms and made a list of those, which called for an abort and those, which didn't. If you hear the audio from mission control during this alarm, You can hear Bales talking "Same type we've had" This refers to the alarms in the sim. So the guys in Mission control were pretty much prepared for this and did a perfect job in preparation and execution of the mission. "Tough and competent" as was the line from Gene Kranz after the Apollo 1 fire.

Wow that’s the kind of stuff I like to watch. So informative.

6:53 Haise, Fullerton, Engle and Truly - Well done Mr. Eyles!

Wow! Thanks for the video! The world owes that guy a great many beers!

Great video. I recommend the podcast "13 minutes to the moon" by the BBC, which is a gem. This issue (and the AGC / Apollo Guidance Computer, as well as many personal stories of those involved) are told in detail

Love this!👏👏😍 Geeking out on all things Apollo Program...such good stuff!

Human ingenuity a true marvel; respect.

Thanks for this very interesting information, I was nine when this took place and remember it well. Amazing achievement.

Some decades ago (in 1969) I worked at MIT/IL on the Apollo missions. I started out as a programmer and then ran a small group that assisted other programmers. One of the programmers that I worked with was Don Eyles, a man chartered to develop the lunar landing software. Here is Don's explanation of what went wrong during Apollo 11's lunar landing. The 1201 and 1202 computer alarms had everyone concerned, and Mission Control made the proper decision to continue landing the LEM. Apollo 11 was successful as a mission.

Have written assembler code with restrictions but nothing like their restrictions. The validation of the software must have been crazy extensive. The mind boggles how they handled change control.

Mr. Eyles is also to be remembered as the programmer who literally saved the Apollo 14 lunar landing mission by crafting manual-entry software workarounds to accommodate an intermittently misfiring ABORT switch.

The compact, efficient code of the early days of computing is essentially a lost art. At University of Michigan in the very early '70s, classmates and I were writing Fortran code that we delivered to the computing center (IBM 360 mainframe era) on punchcards. In fewer than 200 instructions, we could simulate the hydraulics downstream of a hydroelectric facility's outlets, or simulate the dynamic response of an automobile suspension to specific roadway and vehicular characteristics. Computing power at the time was VERY expensive, and the wait time to have your program batched into the machine could be many hours - so you learned to write efficient code with error-free syntax, as errors cost you both dollars and wait time. I made many trips to the computing center in the middle of the night, as turnaround was usually much quicker then.

And what they omitted is something I learned from another video, the radar was turned on when it wasn't needed but in addition, Buzz was asking the computer to update him on the progress of the lunar landing and that put the computer over the edge so it restarted everything except his inquiry and he figured out after it happened twice that it was he who was causing the code.

From what I understand, the overload had nothing to do with Aldrin's setting of the Rendezvous Radar (RR) switch on per the Apollo 11 flight plan. It came from a design fault in not phase locking the Coupling Data Unit (CDU) power supply with the Attitude and Translation Control Assembly (ATCA) power supply. By design, the CDU relied on the phase of ATCA power supply to be in phase with its own to infer the position of the antenna, and they weren't in phase, thus the CDU generated spurious interrupts which overloaded the AGC when the RR was in Auto or Slew mode.

Interesting interview. Amazing that the Apollo flights got to the moon with equipment that only a generation later seems antiquated and almost primitive technology.

It’s amazing that Don Eyles, who is responsible for having written most of the computer code for the Apollo 11 LEM landing phase, is not only still alive, but agreed to this interview, to explain what almost caused a disaster for Apollo 11. It was good to hear him say that the code itself was sound, but apparently did not take into account “what if somebody flipped a certain switch that would overload the computer and cause it to reboot at its most critical hour?” It was good for him to have stayed on at MIT to debug the LEM Landing, phase code so that he could write a version 2.0 to that code that would know how to react if that (somebody flips a certain switch that ain’t supposed to be flipped) were to happen again. Whereas had he been fired or quit, a new landing phase code writing committee would have to start from scratch, that would likely increase problems with subsequent Apollo moon landing missions.

Thanks for this.. I saw Buzz Aldrin speak for an hour here in NZ in 2010 about his experiences 👍🇳🇿

Besides the memory constraint, the developers had also a great deal of pressure to do it right. If an error in the code could result in the astronaut dying and crushing the dream of a nation you're gonna do it right no matter what.

I'm Don Eyles, one of 400, 000 Apollo Program legends and I used to look like hippie Matt Damon.

What an amazing story and legacy. From unemployed to coding NASA computers at such a young age. Love that he kept all these old papers and items from his NASA days. Can imagine he has entertained quite a few house guests.

Great story into the past, thank you.

Actually Mr Eyles was only one of several people who made up the coding team and he wasn'tt the person behind the error coding that saved the Moon Landing, it was Margaret Hamilton. It was at her insistance that additional error coding was implimented and she then also wrote the first asynchronus coding which enabled the on board computer to keep going and not crash due to the overloading. Therefore ensuring that the most vital operations were still carried out and therefore enabled the Moon landing to continue. She worked her way up from a junoir tech to become the Lead and NASA's first software engineer. It was her coding that saved the moon landing and she was honoured by President Obama with the highest civiilian award.

What, to me, was the most DARING portion of the Apollo 11 mission: When the Lunar Module was ready to descend the last few feet to the Lunar Surface, the LEM Guidance and Navigation Computer experienced a VERY severe malfunction. The malfunction code that was displayed to the astronauts indicated the computer was being swamped by the number of inputs coming in. That meant the computer could not accomplish all the computational tasks it had to perform to continue its control of the space craft. VERY DANGEROUS situation and the malfunction occurred only MOMENTS from the final approach and landing. Given that condition the SMART thing to do would have been to abort the landing....hit the "Abort" button.... and ascend back up to the Command Module. But that's NOT what the astronauts did. Neil Armstrong took manual control of the LEM...a VERY "SKETCHY" move...because he had little to no experience flying the vehicle manually. Yet...that's what he did...and as we all know.... landed the LEM safely on the surface of the moon. What a guy! What a pilot! (He SHOULD have been reprimanded for doing what he did...But thank God he DID do...what he did!)

There is a rare NASA broadcast where they revealed that in a landing simulation an error code had come up and they had a hard time finding out what to do and they did an abort. They instructed the software team to analyze every error code and get a procedure of exactly what to do for each code if it came up. - That likely saved the mission. Amazing.

Buzz also broke the switch for the engine to lauch the ascent back up to the command module. He jammed a felt tip pen into the switch to complete the circuit and lauch the engine.

I bet this guy could write some amazing C64 Demos!

3:35 more like DOS being loaded into an XT with floppies, runs off the storage, Macs with CDs usually had onboard OS

Fascinating. Thank you.

The Apollo Guidance Computer was amazing for the time period it was built and its application. In the 1960s computers took rooms full of computer equipment. Here they had a make for its time a very compact, low in weight, small in size computer that was able to fit in the Apollo Command Module and the Lunar Excursion Model and still do the guidance job.

1:09 strange how innocuous events have profound future consequences. He was obviously the right person for the (future) job, but if he hadn't stumbled into the instrumentation office that day someonelse who may not have known what to do during the Apollo 11 Mission may have gotten the job and the Apollo Mission may have ended very differently.

As a programmer myself, this story is as scary as any horror film. Makes my blood run cold.

It was the day after my 14th birthday. It was incredible. Fast forward too 2005 when I was at Cape Canavaral and saw the shuttle launch. Mind boggling!

Would have been nice if they'd mentioned he had a BS in Mathematics from Boston University when he was hired. So though he didn't have programming experience per se, he definitely had training in logical/mathematical thinking. And he was bright enough to be bored with differential equations in his senior year to drop out, though he would return for his degree. I'm not downplaying his story, it's most definitely inspirational. They were TRUE brilliant creators. No one knew how to write code for what was required. NO ONE. They had to figure it out. He's written his autobiography. You can find it on amazon books. Wound up at MIT purely by chance. It's all incredibly fascinating.