Building Rockets

One of the presentations I never got to do (due to Lock down) was on Building Rockets and how we can learn good software practices from the evolution of rocket building over the many years

The MVP

During the early years of Space Craft development Rockets and Shuttles had a very high Minimum Viable Product, famously the Space Shuttle required to be reusable, transport humans to and from space and most importantly be space worthy for its maiden voyage.

This increased development costs and because it needed to ferry Humans meant that testing had to be more rigorous, more features had to be included and notably held a zero risk attitude.

In comes SpaceX the rocket engineering arm of billionaire philanthropist Elon Musk's progressive portfolio of companies.

From the get go SpaceX had a smaller MVP "Deliver Satellites To Space" so from the offset SpaceX was able to make money doing just the MVP all while having its sights firmly set on re-usability and eventually human space flight.

Iterative Development

SpaceX has famously added new features to its Rockets as its gone along, starting in 2010 with its first attempted parachute landing of the rocket into the ocean or on Flight 6 with a successful delivery of a Satellite into orbit with a controlled re-entry of the first stage.

As they progressed the milestones built up;

• 2014 - Flight 9 - First time Flying with Landing Legs
• 2014 - Flight 14 - First attempt to land a Rocket
• 2015 - Flight 15 - First successful landing on Land of a 1st stage rocket
• 2017 - Flight 32 - First commercial relaunch of a 1st stage rocket and recovery of fairing
• 2019 - Flight 69 - First Crew Dragon Space capsule launch
• 2020 - Flight 85- First Manned Crew Dragon launch for NASA to the ISS

I love this video as a demonstration of that iterative approach;

Learning's

Space X had a Rocket which within a few years was making them money, it allowed the garnishing of data from live environments. Once a 1st Stage had separated from the 2nd Stage they were free to do what they wanted with it.

Every delivery had a new test at the end which meant while their MVP of putting Satellites in Orbit was been achieved they could iteratively add new tests to that Production environment, new suites of sensors and logging tools.

They deployed multiple version of their product and tested features on non customer rockets before adding them to existing rockets. They famously added landing legs to a rocket which was never going to land on anything solid. They flew with the legs for 3 missions opening them up just to dump the rocket in the ocean. They were toggled off effectively…

Ultimately the technical skills to build rockets may be different in the same way a back end developer and a front end developer may have different skill sets but all can benefit from similar processes.

An MVP allows you to continue to bring in revenue and combined with small iterative changes can bring more resilience and stability to the process

Why have one test environment, when you can have many. By using cheap , repeatable and quickly built test environments Engineers are encouraged to try more things with a higher chance of failure. Engineers can learn as much from failure as they can from success.

And ultimately why spend Time, Effort and Money on building something you just want to crash into a rock 

PS - Wouldn't it be great if our Production Deployments went this well...