NASA’s Apollo 11 mission secured its place in history by marking the first visit of human beings to the moon – and their safe return. This so-called century project, ambitiously pushed by John F. Kennedy, was many things: From a political statement in cold war times to a key landmark in the development of the human race. Even so not everyone may be aware that it was also a sophisticated IT project. No doubt it demanded all software skills available in the late 60s – a very early stage of computer science. Sebastian Hahn, Seerene’s Director of Product & Analytics had a brief look at the source code and would like to know more. Are there any ‘assembly’ (asm) archeologists out there to join us digging deeper? Do you speak assembly?
In the beginning there was Margret. The 32-year-old Margret Hamilton was leading developers of the team responsible for the coding for the Apollo Guidance Computer for the spaceship’s command and lunar modules.
Margaret Hamilton – Leader of the 24-member developer team behind Apollo 11 with a printout of the Apollo flight software (Picture: Wikipedia)
By managing such an important project at such an early stage of computing and coding teamwork, the young genius invented some techniques and standards that are still in place today and delivered a piece of software ahead of its time. Viewed from today’s perspective the project appears antique since the code was written in assembly and stored as core rope memory, approaches that are quite outdated today. While being a well-kept national secret at the time the whole source code was published on GitHub by former NASA employee Chris Garry and is now free for everyone to see.
It was only lately that we stumbled over the code on GitHub and asked Sebastian Hahn, our Director of Product & Analytics, if it would be possible to analyze it with Seerene tools. He gave it a quick look to see if he could give that artificial construct of assembly code a graphic shape, graspable for everyone. And probably even get meaningful insights out of the static code.
Sebastian Hahn - Director of Product and Analytics at Seerene is responsible for the functionality of the Seerene Digital Engineering Platform. He is used to making complex software systems transparent.
“Current projects are quite transparent for us with regards to parameters like, for example, how much effort was spent where. This is not possible for such a historic project like the Apollo software as we cannot look into the actual project development. Yet, analyzing its static metrics with our Seerene tool landscape and visualizing it on our platform gives me the feeling of having history right at my fingertips. Even in some of our current projects we are used to deal with complex situations like legacy software, particularly when it comes to mining corporate systems. But of course, Apollo 11 still stands out massively: A project in the very early stages of coding history and principally written in assembly code is more than unique for us and was a real fun challenge.” Sebastian explains.
Image: Seerene analytics of the assembly code for Apollo 11’s Guidance Computer
This is how the Apollo 11 flight software looked as it was first visualized on the Seerene Digital Engineering Platform. Each block represents Code Unit. You can see that the display and keyboard system, amusingly called “pinball game buttons and lights”, was containing the most complex functions (in terms of other function calls) of the overall system. Imagine that code for what is a simple button today is the most complex code here!
So, what can we do after Seerene made the code transparent? “Assembly of course doesn’t have modern programming language structure, but you can find basic similarities. For example, there are obvious things like the ratio between lines of code and functional lines of code, which are not comments or whitespaces. This ratio between commented lines to functional lines of code can give deeper explanation of why something was written. Furthermore, there are more sophisticated parameters like the total or average complexity of functions per code unit. This can be measured by a simple metric such as the amount of statements they include. We asked Seerene 'How many assembly functions do we have in a code unit with more than 5, 8 or even 10 sub-statements?'", Sebastian tells us. This is similar to modern metrics such as the amount of lines of code deeply nested which we use to measure complexity.
The Seerene tool landscape makes it quite easy to fetch metrics that can cover those issues just by adding the right regular expression. This is actually done often in projects to improve database functions in SQL-statements. For example, to find out how many sub SELECT-statements are used per .sql file. If this parameter is high, it makes the code hard to understand for developers. "Just by reading the comments I felt like being taken back in time and I could guess some of the processes behind the project. The comments and naming also expressed a great deal of individuality – sometimes they appear quite casual.", Sebastian states.
“It would be great to sit down with someone who understands the code and is deeply interested. Is there anyone out there, like a software archaeologist, who is curious about revealing more on the Apollo 11 assembly code?” he asks. Although the code can be completely analyzed, we would need someone to ask a variety of questions that Seerene can answer. We at Seerene are quite sure that if somebody wants to do some research on this, it is quite likely that our platform will come up with some interesting and surprising results. So, don’t be shy, software archaeologists, reach out!