Flying to the Moon is like developing on your laptop
Lesson XII from the lunar landings
As I write this, it has been just over 51 years since the first time mankind landed on the Moon in Apollo 11 and exactly 49 years since the first heavily science-oriented mission of Apollo 15.
A common question I’m asked when I talk about the lessons from the Moon landings is “Why don’t we still fly to the Moon?” and “Is it true that we no longer know how to fly to the Moon?”
When I consider software development, these questions a very similar to the eternal cries of “My new feature worked on my laptop, why doesn’t it work in production?” and “You built it, why don’t you know how it runs?”
The questions are similar in that they are all predicated on the idea that doing a thing once means we can do it again and again just as easily. Even worse — the mistake of making something difficult look easy means that you’re then expected to do it again at the drop of a hat and with little expense.
As we’ve discussed before, both software development and reaching the Moon benefit from iteration — don’t bite off more than you can chew and try to deliver all your goals in one big shot, but start small and test each little solution or Minimum Viable Product (MVP) as you go. Each MVP will build on the previous one and be bigger and better. In this way, you’ll eventually reach your goal much more safely than if you had tried to do too much too fast. When one looks at the list of Apollo missions, each new mission built on the lessons of the previous one until NASA achieved the G mission — the MVP of actually landing on the Moon.
The only requirements of a Moon landing (as defined by president Kennedy in 1961) were ”before this decade is out, [of] landing a man on the moon and returning him safely to the Earth”. In other words, once Apollo 11 returned safely, then the primary goal had been achieved. But NASA did not rest on its laurels and continued to fly to the Moon.
After the first G landing came the H missions — demonstrating that Apollo 11’s success was not a fluke and that landing on the Moon was a repeatable process. Each of the H missions was more precise, with more complex systems, and demonstrated more technical capabilities.
After the H missions came the J-s. A J type mission did not merely aim to repeat Kennedy’s goal of landing on the Moon but showed that humanity could survive, function, and succeed in working on the Moon.
Each J mission was a tour-de-force of scientific inquiry and technological marvels.
(before the Apollo missions, who would have imagined carrying a fold-out battery-powered car to the Moon?!)
From a software development perspective, all these missions after the G mission improved the functional requirements such as precision landing, amount of time spent on Moon, scientific equipment carried to the Moon, the distance the astronauts could travel from the spacecraft, the variety of experiments they performed and the number of rocks & photographs they brought back the Earth.
As discussed previously, functional requirements are the “What” requirements your solution delivers. What is the business value? In the case of a Moon landing, the business value is precisely what the Apollo astronauts achieved — reaching the Moon, performing their work there, and returning home.
The non-functional requirements are the “How” requirements — How will we do it? How expensive is it going to be? or rather, How cheaply can we do it? How dangerous is it going to be? Who can do it? How long will it take to prepare a new mission? and so on. While you don’t need to achieve non-functional requirements in your first MVPs, unless you can demonstrate some of them (having a sustainable budget, being safe enough) the project will not be long-lived. Because these issues are often not needed for the first use of the solution but are relevant for the long term success of it, they are often called “business as usual” or “day 2” requirements.
Nearly every feature demonstrated by the final Apollo flights was functional — get more science, stay on the Moon for longer. The final mission, Apollo 17, was no cheaper or easier or simpler or safer than any of the previous missions — simply because this would not have improved the functional goals of the missions in any way.
The Apollo Moon landing program was designed to get people to the Moon and bring them back. Period. Nothing more, nothing less.
It did this spectacularly but did not concern itself with the long term issues such as sustainability, price, or risk which non-functional requirements solve.
For these issues, NASA created a department in the 60s (before the landings were even a success) called Apollo Applications Program.
The Apollo Applications Program (AAP) was supposed to supply a solution to all the non-functional requirements — how long can humans live in space, how can we return to the Moon cheaply, how can we train non-pilots to be astronauts more easily, and so on. Unfortunately, AAP was under-budgeted and did not have an opportunity to answer most of these questions. It was later replaced in the 70s with the Space Shuttle which also had non-functional requirements as a major goal — How cheaply can we fly people into space? Can we fly non-pilots into space? Discussions and lessons from these programs will have to wait for future articles in this series.
Now, what does all this have to do with your laptop?
If you’re a software developer and you’ve created a new product, feature, or solution and it works fine in your development environment that means you’ve achieved all your functional requirements and you’re ready to deploy your shiny new product to the production environment. That’s great!
But… have you taken into account the non-functional requirements? Do you know how to monitor your solution and solve any problems that might arise during day to day work? Do you know how to back it up and restore it if there’s a critical failure? Do you know how to scale it up or down when more people use it than you’ve expected? Do you know how to upgrade it without any downtime?
If you don’t know how to answer these questions then you’re going to be in the uncomfortable position, after your solution has been running for a while, where you’ll be asked: “You knew how to deploy it 2 weeks ago, why can’t you keep it running today?”
Like NASA, you’ll be able to go to the Moon, but you won’t be able to continue going there again and again. To be able to sustain your solution, to be able to keep it going and solve your client’s problems, you’ll need to add these non-functional (or day-2) requirements.
Don’t put yourself in a position where you need to add on your day-2 requirements after the fact. Invest some extra time during development and get them right at the first opportunity!
If you’re working on developing applications on the Open Shift Container Platform (or supporting them), you can access a free video course on Day-2 operations right here.
The films showing the Lunar Roving Vehicles (aka Moon Buggies) were filmed using 1960’s technology and have recently been redone using modern video processing technology and AI capabilities. Here are a few links to videos you might enjoy (all unaffiliated with myself or with IBM):
Articles in this series:
For future lessons and articles, follow me here as Robert Barron, on Twitter @flyingbarron or Linkedin.
Bring your plan to the IBM Garage.
IBM Garage is built for moving faster, working smarter, and innovating in a way that lets you disrupt disruption.
Learn more at www.ibm.com/garage
