Skip to content

Apollo 11 Code Review

Stardate 23018.1 or 21st of July 1969, mankind takes its first steps on the Moon.

Article
·
January 10, 2024
·
·
Tecknoworks
Apollo 11 Code Review

Stardate 23018.1 or 21st of July 1969, mankind takes its first steps on the Moon. Mission commander Neil Armstrong and pilot Buzz Aldrin safely land the Lunar Module Eagle on the surface of the Moon. Over 400 people worked on Apollo’s software, which helped people safely land on the Moon. You can bet they followed good software development practices. As a bare minimum, we know the software was tested, reviewed and approved. It was written in a special version of the assembly language. The code can be found on GitHub. Let’s take a look, and do a quick Apollo 11 code review.

Readability is important

All the source code for Luminary099 has 64.992 lines. There are 40.202 lines of code. There are no files without comments, 31.443 of the lines contain a comment and there are 5900 blank lines used.

● The software was submitted by 1 person and approved by 6 other people.

● Temporary does not exist in programming. It is a myth! Hope is not a strategy.

● Respect your users, but don’t trust them.

● Humor is essential for landing people on the Moon.

● Trashy little subroutines
● Numero mysterioso
● Burn baby burn
● Shakespeare quote
● Hello there. Goodbye. Come again soon.

Apollo 11 Code Review Apollo 11 Code Review

Errors will happen. Write software with that in mind.

“Due to an error in the checklist manual, the rendezvous radar switch was placed in the wrong position. This caused it to send erroneous signals to the computer. The result was that the computer was being asked to perform all of its normal functions for landing while receiving an extra load of spurious data which used up 15% of its time. The computer (or rather the software in it) was smart enough to recognize that it was being asked to perform more tasks than it should be performing. It then sent out an alarm, which meant to the astronaut, I’m overloaded with more tasks than I should be doing at this time and I’m going to keep only the more important tasks; i.e., the ones needed for landing…

Actually, the computer was programmed to do more than recognize error conditions. A complete set of recovery programs was incorporated into the software. The software’s action, in this case, was to eliminate lower priority tasks and re-establish the more important ones … If the computer hadn’t recognized this problem and taken recovery action, I doubt if Apollo 11 would have been the successful moon landing it was.” — Margaret Hamilton, Director of Apollo Flight Computer Programming MIT Draper Laboratory, Cambridge, Massachusetts, “Computer Got Loaded”, Letter to Datamation, March 1, 1971.

Bonus: SLOCCount output for Luminary099

SLOCCount is a suite of programs for counting physical source lines of code (SLOC) in potentially large software systems.

This is the output:

  • Total Physical Source Lines of Code (SLOC) = 40,202
  • Development Effort Estimate, Person-Years (Person-Months) = 9.67 (116.06) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
  • Schedule Estimate, Years (Months) = 1.27 (15.22) (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
  • Estimated Average Number of Developers (Effort/Schedule) = 7.62
  • Total Estimated Cost to Develop = $ 1,306,477 (average salary = $56,286/year, overhead = 2.40).

References

https://en.wikipedia.org/wiki/Apollo_11
http://www.htius.com/Articles/r12ham.pdf
https://www.youtube.com/watch?v=hyhI85Rd1kI
/r/ProgrammerHumor
https://en.wikipedia.org/wiki/File:Margaret_Hamilton.gif
https://en.wikiquote.org/wiki/Neil_Armstrong
http://www.amazingwomeninhistory.com/
http://www.dwheeler.com/sloccount/sloccount.html
https://www.youtube.com/watch?v=bJEnTE8kcFY 

Do you have an idea for some code we should review? Get in touch and let us know!

Apollo 11 Code Review

AI Delivery Squad

If your organisation is at the moment where AI needs to move from lab to production, this is the team that gets it there and stays to run it.

Production AI Systems Engineering: we score ten production dimensions, prove it on your real data, deploy it and keep it running.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
AI This Week: The Harness Arrives | Week of July 14-July 20, 2026
Production AI

July 20, 2026

AI This Week: The Harness Arrives | Week of July 14-July 20, 2026

Every week I filter roughly 15 AI newsletters down to what matters for production teams.

Read article
AI This Week: Fault Lines | Week of July 7-July 13, 2026
Production AI

July 13, 2026

AI This Week: Fault Lines | Week of July 7-July 13, 2026

This week had one theme: fracture. Three frontier labs shipped models in 72 hours.

Read article
AI This Week: The Stress Test | Week of June 29-July 5, 2026
Production AI

July 7, 2026

AI This Week: The Stress Test | Week of June 29-July 5, 2026

Eighteen days without a frontier model is a long time when your production systems depend on it.

Read article
AI This Week: The Control Layer | Week of June 22-28, 2026
Production AI

July 1, 2026

AI This Week: The Control Layer | Week of June 22-28, 2026

This was the week everyone stopped fighting over AI intelligence and started fighting over AI control.

Read article
AI This Week: The Tooling Arrives | Week of June 15-21, 2026
Production AI

June 22, 2026

AI This Week: The Tooling Arrives | Week of June 15-21, 2026

This was the week the platforms stopped talking about AI and shipped infrastructure for it.

Read article
AI This Week: The Sovereignty Fracture | Week of June 8-14, 2026
Production AI

June 15, 2026

AI This Week: The Sovereignty Fracture | Week of June 8-14, 2026

This week had one theme: the sovereignty fracture.

Read article
AI This Week: The 80% Threshold | Week of June 1-7, 2026
Production AI

June 8, 2026

AI This Week: The 80% Threshold | Week of June 1-7, 2026

This week had one theme: the 80% threshold.

Read article

More articles