On the Timelessness of “The Power of 10”
Often attributed to NASA (though space nerds like me will be quick to point out that JPL and NASA are intertwined but not the same), The Power of 10: Rules for Developing Safety-Critical Code is a set of principles outlined by Gerard Holzmann in 2006. Not for nothing, he was awarded the NASA Exceptional Engineering Achievement Medal in 2012 for his contributions to software development.
Every so often, this document resurfaces (though it’s always available), and someone inevitably posts it on Hacker News or Medium. And, just as predictably, another person follows up with a blog post arguing that the rules are outdated, short-sighted, or otherwise flawed.
So, for this particular hype cycle, I want to chime in and explain why—despite all the criticism—the document not only remains relevant but will likely stay that way for the foreseeable future.
Whatever you think of the document itself, I think we can all agree on one thing: engineering and software development for space is, quite literally, rocket science. Just check out one of my older blog posts on the subject
Follow the rules? (And what comes next!)
The most common mistake developers make when reading these rules is—ironically—focusing too much on the rules themselves. At first glance, the guidelines seem outdated, especially given the way NASA/JPL builds software. That makes them easy to dismiss or even ridicule.
Take rule #4, for example:
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.
Of course, almost nobody prints out their code these days (unless, apparently, you work for Elon Musk).
But dismissing this rule based on its paper-based limitation would be missing the point entirely. Instead, let’s look at the reasoning behind it:
Each function should be a logical unit in the code that is understandable and verifiable as a unit. It is much harder to understand a logical unit that spans multiple screens on a computer display or multiple pages when printed. Excessively long functions are often a sign of poorly structured code.
This is where it’s at folks! The key idea isn’t about paper at all—it’s about code readability. Sure, whether 60 lines is the right threshold is debatable, but the core principle holds: shorter functions are easier to understand and verify. I’d argue that keeping functions within a single screen’s view in an IDE remains a modern interpretation of that rule — and when I check my IDE, that size limit turns out to be roughly the same number of lines. Who knew?
Let’s look at another example — here is rule #10:
All code must be compiled, from the first day of development, with all compiler warnings enabled at the most pedantic setting available. All code must compile without warnings. All code must also be checked daily with at least one, but preferably more than one, strong static source code analyzer and should pass all analyses with zero warnings.
On the surface, this sounds excessive — perhaps even unrealistic for typical software projects. And maybe, we have to acknowledge that NASA/JPL code is often responsible for equipment worth hundreds of millions of dollars, not to mention human lives. That’s a level of responsibility that - thankfully - most of our code will never have to bear.
And yet, even here, the reasoning behind the rule is indisputably solid:
There are several extremely effective static source code analyzers on the market today, and quite a few freeware tools as well. There simply is no excuse for any software development effort not to use this readily available technology. It should be considered routine practice, even for noncritical code development.
See? The wording of the explanation is much less rigid than the rule itself, but the message is clear: There is no reason not to use the available tooling!
The Real Value of “The Power of 10“ and beyond
Instead of dissecting every rule in the document, I encourage you to read through it yourself. But now, rather than just skimming the surface, try to understand the reasoning behind each principle.
Trust me, you will walk away a better developer.
For one, these rules (and their underlying rationale) remain incredibly useful even outside of safety-critical software. But more importantly, learning how to engage with rules like these — separating their intent from their (rigid) wording or applicable language or framework — is what truly makes you a great software developer.