What Made Apollo a Success (1/3): The Technology

How to Build a Spaceship Properly

Over the centuries, there have been many innovations that have advanced humanity. The Apollo spacecraft (and its launch vehicle, which is not covered in the articles) certainly belongs to this category. In 1969, three astronauts embarked on the dangerous journey to the Moon and made history with their landing. In total, humans landed on the lunar surface six times, and once, a crew narrowly managed to return to Earth after an explosion on the way there. Overall, the Apollo program was one of the most expensive but also one of the most successful large-scale projects in human history. In our small article series, we want to take a closer look at the principles that led to these successes and apply them to web projects on the Internet. After all, that is our industry.

Use of Established Technologies

The first point that Kenneth S. Kleinknecht, an engineer and scientist in the Apollo program, mentions in his article about the development principles of their spacecraft is the use of established technologies. Although NASA engineers operated at the edge of scientific, engineering, and manufacturing knowledge with the lunar module, they made sure to use technologies and manufacturing methods that were already tested and proven wherever possible. Their goal was not to develop a completely novel spacecraft but one that consisted of as many known components as possible.

This principle can be directly applied to web design. As web designers, we can either rely on a wealth of proven technologies that date back to the early days of the Internet or utilize the ever-new innovations that our industry constantly develops. The great art is to recognize when something new actually offers enough added value to justify the risk that it may become obsolete in just a few years. What often backfires is incorporating new and unproven techniques in areas of a website or web app that are "mission critical," where the entire project could fail. And that is not as rare as one might think. Kleinknecht's advice to use only established technologies is therefore as relevant as ever.

Strong Focus on Technology Reliability

One aspect that held a very high priority at NASA in the development of their technology was the reliability of the technology used in all conceivable mission scenarios. The list of rigorous tests that they subjected their hardware—and software—to seems almost endless. Every component was tested in all conceivable scenarios and was only integrated into the spacecraft once it had proven itself in all tests without exception.

Testing is sometimes taken more and sometimes less seriously in the world of developers. However, it is essential for all projects, whether large or small. I can recall instances from my time as an employee in large agencies where things went wrong. For example, a colleague copied a contact block from one website to another without testing it afterward. For weeks, a hotel received inquiries that were actually meant for a completely different hotel because its number was still stored somewhere in the system. The error was eventually noticed by the client, which was at the time a significant blow to the agency's reputation - and rightly so.
From seemingly trivial technology like contact forms to complex functionalities—much can go wrong on a website or app. Here, only a strong focus on the reliability of the technology used and good checklists can help. And, of course: testing, testing, testing ...

Compliance with Safety Standards

In every industry, safety standards eventually emerge. There is a good reason for this. Each industry has its specific safety risks that have been identified and documented in the past—sometimes very painfully and expensively. These risks also existed in the Apollo program. They were identified in advance, ranging from cracks and leaks to short circuits, loose fittings, and line breaks, among others. Subsequently, appropriate standards were developed for these risks, and compliance was strictly monitored. Not least because of this, even the potentially fatal explosion of an oxygen tank in Apollo 13 did not lead to a loss of the crew. Here are some features in the design of the Apollo spacecraft that made them so safe:

• Triple Redundancy: The systems of the Apollo spacecraft, including control, navigation, and communication, were designed to be triple redundant. This means that there were multiple independent systems that could take over in the event of a system failure.
• Emergency Procedures: The astronauts were extensively trained in emergency procedures. This included training for various scenarios, including system failures and emergency landings.
• Safety Checks and Tests: Extensive safety checks and tests were conducted before each launch to ensure that all systems were functioning properly. This included both simulations and physical tests of the spacecraft and its systems. We have already touched on this point above.
• Communication Systems: The Apollo spacecraft was equipped with robust communication systems that allowed the astronauts to stay in constant contact with the ground station for support and instructions.

There are also numerous risks and dangers on the Internet. Often, one is seen as a killjoy for pointing them out. However, being aware of these dangers is already an important step forward. Even better, though, is to take the numerous safety standards for operating websites and apps seriously and adhere to them. Design features of a secure website include, for example:

• Redundant Design: It doesn't matter much, for example, if a visitor cannot or does not want to use JavaScript. The website and its essential functions will still work.
• Security Updates: Regular security updates are essential to keep a content management system secure and up to date and to close potential attack vectors early.
• Emergency Plans and Backups: Clear plans for emergencies not only help prevent issues but also ensure that damage is limited if something does happen.
• Agency Availability: We are reachable for our clients through many channels and can respond immediately in emergencies.

Minimizing Maintenance and Testing During Flight

In this regard, the US space program differed significantly from that of the Soviet Union. While the Americans had the necessary resources to test practically all critical components on the ground before they were integrated into the spacecraft, Soviet developers could only test many systems in flight. This led to early and significant successes for the USSR, but in the end, only one nation landed humans on the Moon. And that was the nation that aimed to keep maintenance and testing during flight to a minimum.

This was not only due to financial resources but also for another reason: Testing and maintenance during a flight can lower the required quality of the parts somewhat—after all, they can be replaced if necessary. However, this was not necessarily needed for the short duration of the lunar missions, and building a part correctly also meant relieving the crews, saving weight, and reducing the overall complexity of the systems.

Similarly, this is often the case with websites. Their lifespan is often perceived as not particularly high. Why invest in sustainable and robust technology when we will soon build a new website anyway? - You would be surprised how often this mindset still prevails in the minds of clients and agencies alike. However, it is neither particularly difficult to build a website that will still function in 10 years nor particularly challenging to minimize the necessary maintenance and repairs. One just has to want it and think about how to best achieve this goal in each case...

What was also made possible by Apollo was the continuous monitoring and analysis of all critical functions from the control center on Earth. For this purpose, over 330 telemetry radio channels were established with the spacecraft during the flight, and about 1100 data channels were set up before launch. This monitoring from Earth allowed the utilization of the entire knowledge and experience of the engineers and technicians on the ground while the crew could focus on the important tasks in the spacecraft.

This is also reflected in our daily practice. Clients who have a maintenance contract for their website with us often do not even notice what the systems in the background are handling—and how we automatically keep an eye on everything. This way, we can quickly intervene in case of an emergency while our clients can focus on their tasks. This relief for our clients is so important to us that we have even included it in our name. Because an adjutant does exactly that: it frees decision-makers from all mundane tasks that are important but could distract them.

Simplification

A part that is not there cannot break. The same applies to a check step that does not need to be performed or an action that does not need to be taken. Simplification in all areas, from the design of the spacecraft to the processes, not only led to a reduction in the weight of the spacecraft during Apollo but also to less distraction for the crew. Every astronaut had to be able to operate all essential functions of the spacecraft in their space suit with their bulky gloves. This meant reducing buttons and switches to an absolute minimum and eliminating all systems and components that were not truly necessary.

Simplification not only ensures more clarity, safety, and reliability but also leads to good design. That is something we have known not only since Jony Ive's iconic simple designs at Apple, nor did NASA invent it. But how rarely do we still find truly functional yet simple design today! Achieving this is not always easy for us web designers either. Our approach at Netjutant is that of "Resilient Web Design." Those interested can learn more about this approach on our website. But here's the gist: We always start a website with the content and functional core and then carefully add only as much as brings real added value to the visitor. This way, we build robust, functional, yet simple and generous websites that we are truly proud of.

Minimizing Interfaces

This topic is more for the nerds among us. And generally speaking, the same principle of simplification applies here, which I just mentioned. When it comes to "interfaces," it is always about multiple components that need to be connected. In the case of the Apollo program, it was the launch pad and the spacecraft, but also the lunar lander and the service module that remained in orbit around the Moon during the lunar landing. For these interfaces, there were clear documentation manuals so that all involved teams knew what type of data should be exchanged over the interfaces. Both the number of interfaces and the amount of data were strictly reduced to the absolute minimum.

Interfaces also exist in many modern web applications, for example, between a content management system and the so-called "frontend," which is the part of the website that the visitor sees. But mobile apps also typically access the data they display through interfaces. Designing and documenting these interfaces wisely enables the efficient collaboration of different developer teams. What is needed for this is a clear focus on the desired functions and the discipline to stick to these functions.

Leveraging Experience from Past Missions

The last point that made the construction of Apollo so successful was that they did not reinvent the wheel but could draw on the experiences of earlier projects, such as the Mercury program. However, this retrospective also requires a conscious decision to engage with previous programs and the humility to learn new things.

I have had the opportunity to gather over 20 years of experience as a developer. That adds up to quite a few mistakes—my own, as well as those of others. All of this makes our websites better than ever today.

However, one does not necessarily have to gain experience only within their own industry to apply it. I hope that with this article, I could make a small contribution to ensuring that the experiences of the Apollo program are not forgotten and that we actively think about how we can benefit from them—regardless of the industry.

What are your thoughts on these questions? What conclusions could you draw for your industry? I would be very pleased to engage in a dialogue with you! And perhaps you would also like to follow Netjutant on LinkedIn — this way, you won't miss any articles. Parts 2 and 3 of this series, which will focus on the processes during a mission and the activities of the crews, will be coming soon.