Enormous schedule pressure was driven by a lack of funds after the Apollo missions. NASA decided to address that by building a largely reusable vehicle with huge lifting capacity, one that could be used for both commercial launches and research.
“The whole programme was designed around saving money because the money wasn’t there.
“It had to come together all at once. It wasn’t like there was going to be a depth of capability and money to go back to the drawing board like there was in the pre-Apollo era.”
After four test flights the flight programme was expanded rapidly.
Mullane visited as US President Donald Trump, perhaps jokingly, asked NASA whether they could get people to Mars during his presidential term.
“Let me put it this way, it’s not going to happen unless somebody can wave a magic wand and quintuple NASA’s budget. It’s a money problem.”
Money, or resources, relieves pressure, allowing people to mitigate risks as much as possible.
“If you’re going to say ‘Here’s the Federal Treasury, take what you want NASA’ … there’s going to be a damn good chance that’s going to happen.”
The shuttles had massive redundancy in their IT systems, Mullane says. Each had five identical IBM computer flight systems on board. Four operated in a redundant set, running identical software and acted as checks against each other in providing crucial flight and sensor data.
If one deviated from the other three, it was shut down.
“As long as you have one, just one, that vehicle is going to fly fine,” he said.
The problem was those four computers all ran the same software.
“If there’s an error in your software it’s in all four of those computers. A software error is going to kill you as rapidly as a hardware error."
NASA’s mitigation philosophy led to the deployment of a fifth IBM computer loaded with software prepared by a totally different team.
A “button of last resort” allowed the crew to immediately switch flight control to the fifth computer, Mullane says.
Training is essential in such situations, Mullane says. Training forced shuttle crew to understand these systems while under extreme stress.
Change can also be mission-critical.
“Better is the enemy of good enough,” Mullane says. “Astronauts and other people at NASA were always afraid of, after a system had been validated, they didn’t want any changes.”
The attitude was one of “If it’s working let’s not screw around with it”. Sometimes changes had to be made, but they had to be well thought-out.
And, if change was required, it was often easier to change hardware than software. That could be validated more quickly.
For IT professionals, the balance between minimum viable product and risk is an interesting one, Certus’ director of marketing Sam Williams says.
“What is ‘good enough’ when it comes to a software release?” he asks. “The space programme can teach us more about that because people’s lives are on the line.”
Ultimately software can have impacts on people, he says, especially when machine learning and artificial intelligence ae being implemented in ways that can have unexpected consequences.
Project failure is endemic in the industry, according to many studies. Williams says “dual-speed” IT can help manage that.
Where systems cannot be allowed to fail, a linear, Waterfall approach can be used for development. Other situations, such as developing apps or certain business applications, could call for a more iterative, Agile, minimal viable product approach.
Last year, Certus acquired Wellington-based enterprise software and application development consultancy Core Technology.