Follow these 3 rules for safe and reliable software development


Mission writing and security critical software have been an ongoing challenge for a long time. Formal best practices are useful and have been around since the days of mainframes. As a systems engineer and professor, I read the early works that attempted to define the best ways to design software, ie “The Mythical Man-Month” by Frederick Brooks, and more derivations. recent.

NASA and the Department of Defense (DoD) both develop critical systems. If software, hardware, or any other part of their complex systems fail, lives can be lost. These professionals need to write code that is as safe and reliable as possible on a daily basis.

A recently rediscovered set of guidelines for developing safe software are The Power of Ten Rules, originally published by NASA’s Jet Propulsion Laboratory. Some may argue that The Mythical Man-Month rule of thumb and The Power of Ten rules are written for specific software languages ​​i.e. Fortran and C, respectively. This argument has a basis for the Power of Ten rules, but much less for the Month of the Mythic Man.

But these arguments miss an important point, namely that these two pieces approach software development beyond the question of language implementation. These tags are intended for the profession of software engineer, and not just for the act of programming.

Here is my slightly edited and scaled down version of NASA’s list of the most relevant rules for software engineers writing in any language:

1. Follow the principle “keep it simple, stupid” or KISS

NASA rule: restrict all code to very simple control flow constructs – do not use goto and similar statements or constructs

NASA Rationale: Simpler control flow results in enhanced verification capabilities and often results in improved code clarity.

2. Design for low coupling and strong cohesion

NASA Rule: No feature should be longer than what can be printed on a single sheet of paper in a standard reference format with one row per statement and one line per statement. Typically, this means no more than about 60 lines of code per function.

NASA Rationale: Each function should be a logical unit in code that is understandable and verifiable as a unit. Excessively long functions are often a sign of poorly structured code.

– The functions must be able to be autonomous (high cohesion) with a minimum number of interfaces with other functions (low coupling).

3. Heed the warnings

NASA Rule: All code should be compiled, from day one of development, with all compiler warnings enabled at the most pedantic compiler setting. All code should be compiled with these parameters without any warning. All code should be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass scans without any warning.

NASA Rationale: There is simply no excuse that a software development effort does not use readily available technology. This should be considered standard practice, even for non-critical code development. The zero warning rule applies even in cases where the compiler or static parser gives a false warning: if the compiler or static parser is confused, the confusing code must be rewritten so that it becomes more trivially valid. Many developers have been caught under the assumption that a warning may be invalid, only to realize much later that the message is, in fact, valid for less obvious reasons.

As NASA software developers realized early on, these rules ease the burden on the developer and tester to establish key code properties in other ways. The paper sums it up well:

“If the rules seem draconian at first, keep in mind that they are meant to check code where quite literally your life can depend on its accuracy: the code that is used to control the plane you are flying on. , nuclear energy crashes a few miles from your home, or the spacecraft that carries astronauts into orbit. Rules act like the seat belt in your car: at first they might be a little uncomfortable, but after a while their use becomes second nature, and not using them becomes unimaginable.

John Blyler is the editor of Design News, covering the areas of electronics and advanced manufacturing. With a BS in Engineering Physics and an MS in Electrical Engineering, he has years of experience in hardware-software-network systems as a publisher and engineer in advanced manufacturing, IoT and semiconductors. John has co-authored books on systems engineering and electronics for IEEE, Wiley, and Elsevier.


Comments are closed.