Writing mission and safety-critical software have been an ongoing challenge for a long time. Formal best practices help and have been around since the time of the mainframes. As a systems engineer and professor, I’ve read the earliest works that tried to define the best ways to engineer software, i.e., Frederick Brooks’, “The Mythical Man-Month,” and more recent derivations.
Both NASA and the Department of Defense (DoD) develop mission-critical systems. If the software, hardware, or any other part of their complex systems fail, lives may well be lost. These professionals must write code that is as safe and reliable as possible and on a daily basis.
One set of guidelines recently rediscovered for safe software development are The Power of Ten rules, originally published by NASA’s Jet Propulsion Laboratory. Some may argue that empirical guidelines of The Mythical Man-Month and the rules from The Power of Ten are written for specific software languages, i.e., Fortran and C, respectively. This argument does have some basis for the Power of Ten rules, but far less for the Mythical Man-Month.
But these arguments miss an important point, namely, that both of these pieces address the development of software beyond the question of language implementation. These guideposts speak to the software engineering profession, not just the act of programming.
The following are my slightly edited and scaled-down version of NASA’s list for the most relevant rules for software engineers writing in any language:
1. Follow the “keep it simple, stupid” or KISS principal
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 translates into stronger capabilities for verification and often results in improved code clarity.
2. Design for Low Coupling and High Cohesion
NASA Rule: No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
NASA Rationale: Each function should be a logical unit in the code that is understandable and verifiable as a unit. Excessively long functions are often a sign of poorly structured code.
-- Functions should be capable of standing on their own (high cohesion) will a minimum number of interfaces to other functions (low coupling).
3. Heed the Warnings
NASA Rule: All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these settings without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.”
NASA Rationale: There simply is no excuse for any software development effort not to make use of readily available technology. It should be considered routine practice, even for non-critical code development. The rule of zero warnings applies even in cases where the compiler or the static analyzer gives an erroneous warning: if the compiler or the static analyzer gets confused, the code causing the confusion should be rewritten so that it becomes more trivially valid. Many developers have been caught in the assumption that a warning was surely invalid, only to realize much later that the message was, in fact, valid for less obvious reasons.
As NASA software developers realized early on, these rules lessen the burden on the developer and tester to establish key properties of the code by other means. The paper sums it up nicely:
“If the rules seem Draconian at first, bear in mind that they are meant to make it possible to check code where very literally your life may depend on its correctness: code that is used to control the airplane that you fly on, the nuclear power plant a few miles from where you live, or the spacecraft that carries astronauts into orbit. The rules act like the seatbelt in your car: initially, they are perhaps a little uncomfortable, but after a while, their use becomes second-nature, and not using them becomes unimaginable.”
John Blyler is a Design News senior editor, covering the electronics and advanced manufacturing spaces. With a BS in Engineering Physics and an MS in Electrical Engineering, he has years of hardware-software-network systems experience as an editor and engineer within the advanced manufacturing, IoT and semiconductor industries. John has co-authored books related to system engineering and electronics for IEEE, Wiley, and Elsevier.