"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."
Sign up for Computerworld eNewsletters.