> Also, what became apparent with Apollo – though it is not how it worked – is that it is better to define your system up front to minimise errors, rather than producing a bunch of code that then has to be corrected with patches on patches. It’s a message that seems to have gone unheeded – in this respect, software today is still built the way it was 50 years ago.
Possibly the most useful part of this interview for working programmers. If you really want things to be bug-free, design them to be bug-free -- don't just squash bugs until you think you've probably found most of them.
(Which approach you take depends on how much you care about bugs versus engineering cost, but there are multiple approaches. You can make reliable software if you're willing to put in the effort.)
Designing a bug free software to meet requirements that are ever-changing is hardly a solved problem.
If you specify a system correctly upfront it is indeed possible to make something very very reliable. But a big part of building nowadays software is requirement gathering as you build (or worse - deploy it) nobody knows what it should do beforehand, and in a lot of times it is impossible (or very very expensive) to know.
The whole thing called XP and agile came out as a way to deal with it.
I can still remember the time when devs battled hard to make business people / clients provide requirements up front - the waterfall model. The Apollo program was brought up constantly as a proof that this is the way.
And then we went “fuck it its never going to happen, lets design a process that recognizes this and allows for _some_ sanity”
What NASA used was the latest iteration of a process that has been in use for hundreds of years, quite well understood. Agile and the like are still in its infancy but I think it has a lot more potential for evolution. And its more recognizing what is that wishful thinking of what could be if human nature was different.
And its not like waterfall is banned or anything - you can practice it to your hearts content, for some domains this is even a good idea (implementing protocols comes to mind, financial, medical etc.).
We’ll see who goes to market, gathers business intelligence and answers the customer’s needs faster/cheaper/better.
It's also important to keep in mind that most of the projects that NASA works on/worked on like Apollo 11 aren't just software projects. They involve massive scales of cutting edge hardware that is developed by independent teams and needs to come together, operate in extreme environments and physical constraints, and all be complete and tested and ready for a relatively narrow launch window. Not to undersell the importance of the software component or the skills and talent of those who developed it, but it's usually only one part of a massive effort. Waterfall with intense requirements gathering and up-front design makes a lot more sense in that context. It's very different than developing software to run on commodity hardware to meet potential needs of a wide range of potential users who may have conflicting needs that they don't even understand themselves. In that case, time to market, extensibility, and the ability to iterate with actual user feedback and production data become much more dominant.
In the overwhelming majority of projects I have worked on - the challenge was less building the right thing incorrectly but building the wrong thing correctly.
As a senior management at one company once told me: "That may be what I asked for, but its not what I want" - which is an extreme view but not untypical in lots of domains.
Some people believe software cannot be truly bug-free. We have living proof that that's not true. Techniques exist for engineering mission-critical software. All software should be held to a higher standard, tbh.
Possibly the most useful part of this interview for working programmers. If you really want things to be bug-free, design them to be bug-free -- don't just squash bugs until you think you've probably found most of them.
(Which approach you take depends on how much you care about bugs versus engineering cost, but there are multiple approaches. You can make reliable software if you're willing to put in the effort.)