Podcast 287: How do you make software reliable enough for space travel?
We discuss ten tips for preventing runaway code when a spaceship is on the line.
Ben Popper
Director of Content
In this episode, we chat about “The Power of 10: Rules for Developing Safety-Critical Code.” After that we discuss Python passing Java in TIOBE’s long running index of popular programming languages. And finally we talk about different mindsets you can adopt as a developer. Are you discipline focused, or results oriented?
Episode Notes
You can learn more about the Power of 10 here.
TIOBE’s latest index can be found here.
Our lifeboat of the week goes to lealceldeiro for answering the question: What does the multi: true attribute of HTTP_INTERCEPTORS mean?
Tags: nasa, power of 10, python, space, space travel, tiobe
8 Comments
Very easy quantum computers with A.I. the end
Simple – send the authors and their families up in the spacecraft.
That actually has been put to work by one of the contemporary dictators of Iran.
Good old Z-schemas spring to mind. Those are designed for creating reliable systems.
I have no experience with spacecraft or medical software. My experience is in large scale banking, investments, payroll, etc., systems with lots of regulations, lots of changes over time due to changing regulations, lots of danger from bad actors both outside and inside companies, and systems with material time constraints that being late or wrong isn’t considered humorous and will get you visits from the fed if you make an error.
Yes, the 10 coding practices using the C language make some sense. I’m sure we all can think of many more.
Considering the bigger picture and assuming things are going to change and humans are imperfect, my experience suggested that a strong, reliable, fault-tolerant, conveniently and reliably updateable, design, along with lots of different kinds of very targeted automatic and manual testing, generated the best results. We also included constantly running dynamic health checks, internally, and externally. We also included log readers that would issue alerts. We also included automatic powerful alerting technology should the system detect it was not feeling well. Finally, we ran dual, and as independent as possible, systems at different disaster recovery locations so we could dynamically switch traffic as needed while updating, repairing, testing, or recovering when things still failed.
Since so many of the areas I worked in involved financial transactions, we always assumed that customers would deliver things late or early or on time, with the correct amount, or too much, or too little, and of course, syntactically incorrect or correct, and finally “in pattern” or “out of pattern”.
The “rule of thumb” that 85% of software was error handling, was pretty good. And that meant we also tested the error handling code and procedures.
Were we perfect in all of these dimensions – nope. But, the degree we were compliant, we found the software just was more reliable and we could enjoy our nights and weekends.
Delphi won’t die. It’s back in the TIOBE. Cool
how do I save this podcast as mp3?
These folks know how to do it: https://www.fastcompany.com/28121/they-write-right-stuff