On December 18, 2023, I found “What made Apollo a success?” on Hacker News. It was a simple link to this 86-page compilation of eight articles1 from the March 1970 issue of Astronautics & Aeronautics, a publication of the American Institute of Aeronautics and Astronautics.
Since I am a huge George Low2 fan, I immediately downloaded it, and started looking for articles written by him.
My interest is part of a larger personal quest to understand George Low, the man. That began for me with the accolades that Terry Butryn, Ken Hammond, and Mike Sadeghpour, fellow alumni of Rensselaer Polytechnic Institute (RPI), gave to him3,4.
I was pleased to find that he wrote the “Introduction” to this document. It is 13 pages that begin this way:
On July 20, 1969, man first set foot on another planet. This “giant leap for man-kind” represented one of the greatest engineering achievements of all time. This article and the others in this document describe and discuss some of the varied tasks behind this achievement.
Low, G. M. (2019, August 27). What made Apollo a success?. NASA Technical Reports Server (NTRS). https://ntrs.nasa.gov/api/citations/19720005243/downloads/19720005243.pdf
NASA-SP-287
As I continued to read and reflect on what Dr. Low wrote, I came to the conclusion that many of the ideas he wrote about were relevant to independent software developers and small teams in a way that demanded my attention, and perhaps yours.
1960s Era Spacecraft Design Principles Applicable to Indy Development in the 2020s
Dr. Low divides spacecraft design into four key aspects:
- design
- test
- control of changes
- interpretation of discrepancies
I focused on his brief summary of spacecraft design principles because the design philosophy that the Apollo Team espoused mirror some of the constraints on full use of software design principles that Indy Developers have faced for my entire career.
The principles of manned spacecraft design involve a combination of aircraft-design practice and elements of missile-design technology: Build it simple and then double up on many components or systems so that if one fails the other will take over.
(Low, 2019)
He goes on to give examples of redundancy built into Apollo: “ablative thrust chambers that do not require regenerative cooling; hypergolic propellants that do not require an ignition source; three fuel cells, where one alone could bring the spacecraft back from the moon”, and so on.
This part didn’t seem applicable to me; I don’t know enough astronautical engineering to be able to relate to this aspect of his guidance without remedial reading.
But the most significant revelations that I found in his writing were what came next. (The emphases placed in this quote are mine, not Dr. Low’s):
Another important design rule, which we have not discussed as often as we should, reads: Minimize functional interfaces between complex pieces of hardware. In this way, two organizations can work on their own hardware relatively independently. Examples in Apollo include the interfaces between the spacecraft and launch vehicle and between the command module and the lunar module. Only some 100 wires link the Saturn launch vehicle and the Apollo spacecraft, and most of these have to do with the emergency detection system. The reason that this number could not be even smaller is twofold: Redundant circuits are employed, and the electrical power always comes from the module or stage where a function is to be performed. For example, the closing of relays in the launch vehicle could, in an automatic abort mode, fire the spacecraft escape motor. But the electrical power to do this, by design, originates in the spacecraft batteries. The main point is that a single man can fully understand this interface and can cope with all the effects of a change on either side of the interface.
If there had been 10 times as many wires, it probably would have taken a hundred (or a thousand?) times as many people to handle the interface.
(Low, 2019)
“Minimize Functional Interfaces Between Complex Pieces”
Adapting what Dr. Low meant to the 2020s involved recognizing the technological limitations of 60 years ago. The Integrated Circuit had just been invented. Therefore, in the mid 1960s, the greatest complexities lay in hardware systems.
Software systems were relatively simple. Today, hardware and software can both be exceedingly complicated.
The “Minimize Functional Interfaces Principle” is Akin to Using APIs Whenever Practical
In 2024 much software development can be done by designing systems that depend heavily on third-party Application Program Interfaces (APIs). Indy Developers should use APIs wherever practical in order to take advantage of the ideas that Dr. Low referred to when he talked about the interfaces between complex pieces of hardware. APIs allow the Indy Developer to be responsible for the unique functionality of his or her app, while leaving interfaces to many services to the deployment and maintenance teams at service providers.
As a practical matter, we Indys may not be able to build anything larger than a small portion of the total system that we develop, launch, and maintain. In Apollo Project terms, that could mean something like only designing and building the Lunar Module, but contracting the rest of the project to commercial aerospace companies.
Continuing with an Apollo spacecraft metaphor, the Saturn Launch Vehicle may be likened to a major API that we use to connect our app to a cloud database, such as Firebase Cloud Firestore from Google or Astra DB from Datastax. Or it could be the API to a Large Language Model (LLM) incorporated while building a Retrieval Augmented Generation (RAG) application.
Many aspects of the Lunar Module could be thought of as the Indy Developer’s core work. But the Lunar Module could also be thought of as a Single Page Application (SPA), built with an SPA framework that Indys often use to express their user interfaces.
The Single Man Principle
When I read what I will call “The Single Man Principle,” I realized that this was a monumental insight into software design principles that could really help an Indy Developer like me.
For many years I have pursued the development of RinkAtlas, a passion project of mine, which is primarily an online directory of all of the ice hockey arenas and park rinks in North America. I built RinkAtlas using recent web application design techniques in each successive redesign or modernization of the site.
- In 2006, this meant creating a classic Google Maps mashup written in a homemade PHP framework (RinkAtlas Version 1);
- In 2016, this meant creating an AngularJS Single Page Application (SPA) that talked to a custom API written in Node.js that front ended Apigee BaaS / Apache Usergrid / Cassandra, OpenStreetMap, Yelp Fusion, and DarkSky / Apple WeatherKit APIs (RinkAtlas Version 2).
This approach was somewhat formalized as a result of my success with RinkAtlas Version 1.
RinkAtlas’ existence as a functioning Google Maps Mashup in 2006 got me consulting projects that previous development success on a number of corporate consulting projects did not.
“The Single Man Principle” is Comparable to Maintainability as a Software Design Principle, which is Extremely Important to an Indy Developer
I learned a lot from working with all of these platforms and APIs, but, I found that the redesign that took place for RinkAtlas Version 2 brought with it unnecessary complexity. This stretched my ability as an Indy Developer to maintain and enhance this version of the web application.
The length of time between RinkAtlas Version 1 and Version 2 was a by-product of the consulting success that I mentioned earlier. As a result, it took me a few years more than I originally expected before I had to substantially retool my developer skill set. One of the ways that I chose to do it was to create a better RinkAtlas, built on top of one of the latest JavaScript SPA frameworks, as well as backend and services API frameworks.
I Haven’t Found AngularJS to be Maintainable
In RinkAtlas Version 2, it wasn’t so much that the parts of the SPA built with services APIs (Usergrid, OpenStreetMap, Yelp Fusion, and WeatherKit) were unmaintainable. But the complexity and iterative obsolescence of versions of AngularJS– and to a lesser extent Node.js– were beyond my ability to keep up with, as an Indy working on a passion project.
Applying Dr. Low’s Single Man Principle to RinkAtlas, I couldn’t easily understand the effect of change on both sides of the AngularJS or Node.js interfaces, between my code and application frameworks. This was particularly the case with AngularJS.
I probably didn’t have the technical perspective on modern JavaScript frameworks to make the decision about whether AngularJS was the right tool for the front end, when I began working on it in 2016 . But as I got deep into the development of the RinkAtlas Version 2 front end using AngularJS 1.2, version 1.3 was released. In hindsight, this should have been a tip-off to me that AngularJS was better suited to teams of developers, not Indys like me.
According to Angular’s current Versioning and Releases document:
In general, expect the following release cycle:
- A major release every 6 months
- 1-3 minor releases for each major release
- A patch release and pre-release (
nextorrc) build almost every week
Keep in mind, Angular’s “Versioning and Releases” is a 2024-era document. To my recollection, there was no such document related to release cadence in 2016, although some effort was probably made to project the cadence at or around AngularJS release 1.3.
If I had known, when I was trying to decide in which SPA framework to write RinkAtlas Version 2, that AngularJS would iterate so rapidly from 1.0 to 1.6– introducing breaking changes along the way; And that Angular (AngularJS Version 2) would be almost a complete rewrite of AngularJS, there’s no way I would have chosen to build on it.
Would Choosing a Simpler or More-Stable SPA Framework Have Led to Further Indy Development Success?
A question I ask myself often is, how relevant is my struggle with framework choices to other Indy Developers, who may have raised more money than I did, or realized greater commercial success?
A team of developers may prioritize using the most full-featured, or simply most popular, SPA framework. They may do this for practical reasons that are appropriate because of the larger scale of their effort. One valid reason that a more full-featured or popular SPA would be chosen by a larger team would be to preserve access to a pipeline of future developer team candidates.
But an Indy has to think about the bandwidth it takes to understand and adjust to breaking changes in a complex framework that is better suited to use by a team. A single person is not always well suited to such an effort.
The answer I’ve come to is, as available developer time decreases, the need to prioritize maintainability over the use of full-featured frameworks increases.
I chose AngularJS 1.x over React because, in 2016, I already saw React as too complex for my understanding as an Indy Developer. Although implementing a successful SPA in React probably would have been more helpful to my consulting business, the best choice for maintainability might have been Vue.js, because of its relative simplicity compared to both AngularJS and React.
Did Choosing Node.js Contribute to Maintainability Issues?
I wonder sometimes if Node.js was the right API construction platform? But I never get very far with that question, considering how small the RinkAtlas interface is to its back-end databases, Apigee BaaS / Usergrid and later Firebase.
In fact the wiring of APIs into the finished RinkAtlas Version 2 application all go through the AngularJS codebase. So, the Node.js-based RinkAtlas API which just front ends Firebase Cloud Firestore today, is a minor consideration.
Control of Changes
Dr. Low goes on in his Introduction to talk about the necessity of processes to manage changes as they occurred within the Apollo Program. Some of what he says isn’t applicable to Indy Developers’ circumstances as it leans heavily on delegation of work within a large organization.
However, there is one paragraph I want to highlight:
Since it is not possible to eliminate all changes, we have to start with the premise that any change will be undesirable. That is, a change will void all previous test and flight experience and, no matter how simple, may have ramifications far beyond those identified by the initial engineering analysis.
(Low, 2019)
The Disruptive Effect of an Unexpected API Loss
The decision Google made to sunset Apigee API BaaS / Usergrid in favor of alternatives like Firebase Cloud Firestore forced me to focus on refactoring the Node.js API for RinkAtlas Version 2 simply to allow it, and the RinkAtlas site itself, to remain in a running state.
Looking back, the impact that this external event had on RinkAtlas was of the magnitude to which Dr. Low referred.
As a result of this decision by Google:
- I ended up having to focus on things like building a one-off Extract, Transfer, and Load (ETL) script to migrate the RinkAtlas arena data from Apigee BaaS to Firebase Cloud Firestore.
- I also had to simplify the front end search function, because RinkAtlas lost the query language (Cassandra Query Language, CQL) that was a core feature of Apigee BaaS, as well as built in geolocation support and nuanced data search and filtering, because Cloud Firestore’s data model didn’t support these features.
Refactoring the RinkAtlas Node.js API was also counterproductive to any effort to iterate the SPA to a more modern version of Angular.
This one change turned the RinkAtlas future features list into a wish list, something no developer of any size would want.
Mission Definition and Planning
George Low talks in some detail about mission definition, and gives examples of different milestones in the Apollo Program that can best be contextualized by reading this section side-by-side with details of the history of each Apollo mission.
In general, Dr. Low said:
The basic principle in planning these flights was to gain the maximum new experience (toward the goal of a lunar landing) on each flight without stretching either the equipment or the people beyond their ability to absorb the next step.
(Low, 2019)
Mission Definition and Planning and The Future of RinkAtlas
I’m sure that Dr. Low’s extensive discussion of mission definition and planning will come into play in implementing the next version of RinkAtlas.
My current plan is to rewrite the SPA in Vue.js5 in order to pull content from the RinkAtlas Blog on to the RinkAtlas Home Page. I hope this would have the effect of exposing arena directory users to news about existing arena changes and future arena development, which at one time was a big feature of RinkAtlas.
Before COVID, I tried to use social media such as X (also known as Twitter) and a RinkAtlas Facebook Page to highlight these stories and point readers to them, because the content integration solution that I described above hadn’t occurred to me.
The suspension of article publishing at the height of the Pandemic had more to do with the conclusion that some readers would have made regarding RinkAtlas’ coverage of arena and business closures– that such coverage had a political viewpoint. I didn’t intend that.
But during the intervening time, I came to the conclusion that writing articles about arena changes and future development would not be noticed unless it was featured on the Home Page, so the blog is on hiatus for now.
Concluding Remarks
Finally, Dr. Low’s summation is quite helpful: attention to detail and dedication to get the job done well. The part where he focuses on the vast number of people that he led is in line with the massive scope of their task.
Spacecraft development, mission operations, and flight crew activities — in reviewing these areas of Apollo, I see one overriding consideration that stands out above all the others: Attention to detail. Painstaking attention to detail, coupled with a dedication to get the job done well, by all people, at all levels, on every element of Apollo led to the success of what must be one of the greatest engineering achievements of all time — man’s first landing on the moon….
(Low, 2019)
Indy Developers have simpler projects and fewer goals that need to be attained.
Footnotes
- I’m not claiming authorship of this NASA pamphlet. I provide this link to a local copy in case NASA changes the NASA Technical Reports Server in some fundamental way without notice to folks like me. This is the original location of What Made Apollo a Success. ↩︎
- George Michael Low manager of the Apollo Spacecraft Program Office and 14th President of RPI. See also George M. Low at the Rensselaer Polytechnic Institute Archives and Special Collections and George Low, the RPI President Who Changed World History on DaveAiello.com. ↩︎
- Mr. Butryn, Mr. Hammond, and Mr. Sadeghpour repeatedly told me over the years what a great man George Low was, how much they learned from being in his presence (as they were students at the very end of Dr. Low’s presidency of RPI), and how much they wish they understood him better than they did as 19 and 20-year-olds. ↩︎
- I knew George Low’s life story from reading The Ultimate Engineer: The Remarkable Life of NASA’s Visionary Leader George M. Low by Richard Jurek. But I struggled to connect what Butryn, Hammond, and Sadeghpour told me to Dr. Low’s life story, because their views of him were more personal reflections about being in his presence, and to some extent, having him as a mentor. I felt that reading Dr. Low’s own writings would help me understand Dr. Low’s personality better. ↩︎
- For reasons discussed in “Would Choosing a Simpler or More-Stable SPA Framework Have Led to Further Indy Development Success?” ↩︎