If it’s safe enough for NASA, then it’s good enough for me (software coding rules)

NASA / JPL Laboratory develop spectacular stuff, and it’s not all rockets and space vehicle of all sorts.

Behind al that NASA has been doing for decades is software, used to monitor and control all their vehicles since the earth orbiters and the moonshots of the 1960s.

I’ve retired from active IT work now, and closed Asia/Pacific Computer Services at the end of 2013 (importantly though, NotesTracker is still available and supported, more about this very soon).

Now I’m an IT end-user and industry observer, and one thing that continues to be disturb and even appall me is how so much flawed and sub-standard software gets dumped upon us by companies of all sizes.

Well, over the decades NASA hasn’t been in the position to deploy any sub-standard applications. When livers depend of application robustness in a manned mission, or a space probe is at the outer edge of our solar system, they can’t debug and alter it very easily (if at al)l. So it has to be as close to perfect as possible right from the start of a mission.

NASA uses a set of coding rules such as “No function should be longer than what can be printed on a single sheet of  paper” to develop top-class applications, and you should consider using such rules when designing and developing your own apps.

Go view a summary of the NASA/JPL Laboratory for Reliable Software methodology at The Power of Ten –  Rules for Developing Safety Critical Code

An application crash?