The Coding Rules NASA Uses When Failure Is Not an Option

I stumbled across something last week that genuinely stopped me mid-scroll: The Power of 10, a set of coding rules written by Gerard J. Holzmann at NASA’s Jet Propulsion Laboratory in 2006.

It is short, strict, and surprisingly uncomfortable to read as a modern developer.

The premise is simple: what should code look like when failure is not something you can quickly patch, roll back, or explain away?

When you are writing software for a Mars rover or spacecraft, “we’ll fix it in production” is not a strategy. So Holzmann distilled decades of safety-critical software experience into 10 rules designed to make code auditable, predictable, and defensible.

No fluff. No cleverness for its own sake. Just hard constraints.

And even though the rules were written for C and mission-critical systems, reading them as a regular developer felt like someone holding up a mirror to every shortcut I have ever taken.

The 10 Rules

These are not comfort rules. They are constraint rules. And that is exactly why they are useful.

1. No complex control flow. No goto, no setjmp/longjmp, no recursion. Keep it linear and predictable.

2. All loops must have a fixed upper bound. A static analysis tool should be able to prove, trivially, that a loop can’t run forever. In that kind of environment, if you can’t bound it, you don’t ship it.

3. No dynamic memory allocation after initialization. No malloc mid-flight. Memory is planned upfront, or it does not happen.

4. Functions must fit on one sheet of paper. One page, one statement per line, one declaration per line. If it’s longer than that, you’re doing too much in one place.

5. At least two assertions per function. Assertions are how you document the assumptions your code depends on. Even if you do not literally add two assertions to every function, the lesson is clear: make your assumptions visible.

6. Declare data at the smallest possible scope. Don’t let variables wander where they shouldn’t. Tight scope means tighter reasoning.

7. Preprocessor use is limited. Only header inclusions and simple macro definitions. No macro magic that warps what the code looks like at compile time.

8. Limit pointer use to one dereference. No function pointers. Every extra * is another thing that can go wrong. Function pointers especially make control flow harder to trace and analyze.

9. Be explicit about ignored return values. If you’re ignoring a return value, say so, cast it to (void). Silence is not the same as intentionality.

10. Compile with all warnings on, from day one. Zero warnings. Not “mostly clean.” Not “we’ll fix those later.” Zero warnings, every day, with at least one static analyzer running.

Why This Hit Different

I’ll be honest, some of these rules felt extreme the first time I read them. No dynamic memory allocation after initialization? No recursion? No function pointers? For a lot of modern software teams, that sounds less like best practice and more like punishment.

But the more I sat with it, the more I realized the point is not nostalgia. The point is legibility.

We hide complexity behind abstractions. We trust runtime behavior too much. We let functions grow because “it still works.” We ignore warnings because they are not blocking deployment.

These rules force you to write code that humans and tools can reason about, code where the behavior is not hiding inside clever abstractions, unpredictable control flow, or three layers of indirection. Code where assumptions are visible. Code where failure modes are easier to see before they become real problems.

Rule 4 alone, functions that fit on one sheet of paper, is something I want to paste above my monitor. How many bugs have I introduced, or missed in review, because a function was doing five jobs at once?

The Bigger Takeaway

The Power of 10 is not just a style guide. It is a reminder that good code should be defensible.

Every loop should have a reason. Every function should have a boundary. Every ignored return value should be intentional. Every warning should be treated as feedback, not background noise.

Here is the line that stuck with me most:

If your code is too clever for tools to reason about, there is a good chance it is also too clever for future-you.

NASA did not write these rules to make engineers slower. They wrote them to make software easier to trust. That mindset is worth borrowing, whether you are building spacecraft, SaaS products, dashboards, APIs, internal tools, or anything people rely on.

Give the original paper a read. It is short, sharp, and uncomfortable in the best way. At least a few of the rules will make you rethink something you wrote recently.

The original paper by Gerard J. Holzmann is freely available and worth the 10-minute read: The Power of 10: Rules for Developing Safety-Critical Code