In 2006, NASA's Jet Propulsion Laboratory published "The Power of 10"—a set of strict coding rules designed to ensure spacecraft software never fails. When your code controls a $3 billion rover 55 million kilometers from Earth, there's no room for error. These same principles can dramatically improve the reliability of your business software, prevent costly outages, and reduce technical debt. Here's what every business leader should know about NASA-grade code quality.
When Failure is Not an Option
If your company's software fails, you might get an angry customer call at 6 AM. Maybe you lose a sale. Perhaps you face a few hours of downtime.
If NASA's software fails, they lose a $3 billion Mars rover—permanently. There's no remote restart. No hotfix. No "have you tried turning it off and on again?"
This is why NASA's approach to software quality matters for every business.
The stakes are different, but the principles are universal. Software bugs cost businesses an estimated $2.41 trillion annually worldwide. Downtime, data loss, security breaches, and lost customer trust all stem from the same root causes that NASA's coding rules were designed to prevent.
In 2006, NASA's Jet Propulsion Laboratory (JPL)—the team that builds and operates Mars rovers, space probes, and countless other spacecraft—published a document called "The Power of 10." It contains 10 simple but strict rules for writing reliable code.
What's remarkable is how applicable these rules are beyond aerospace. They represent decades of hard-won wisdom about what makes software fail—and how to prevent it.
The 10 Rules That Keep Spacecraft Running
Let's examine each rule and what it means for your business software.
Rule 1: Keep It Simple—Avoid Clever Code
NASA's Rule: Restrict all code to very simple control flow constructs. Do not use goto statements, recursive calls, or complex branching.
What This Means:
Code should be straightforward and linear. When someone reads it—whether that's a new team member, an auditor, or the original developer six months later—they should be able to follow the logic without a decoder ring.
Why It Matters for Business:
"Clever" code is often the enemy of reliable code. That brilliant one-liner that saves 10 lines? It's also the thing nobody can debug when it breaks at 2 AM.
Complexity hides in:
- Deeply nested if-else statements
- Callbacks inside callbacks inside callbacks
- Abstractions that obscure what's actually happening
- Shortcuts that "work" but nobody understands why
The Business Impact:
- Maintenance costs skyrocket when code is hard to understand
- Onboarding slows down when new developers can't read existing code
- Bug fixes introduce new bugs when the original logic is unclear
- Knowledge walks out the door when the one person who understands the "clever" code leaves
The Principle: Good code is boring code. If it's exciting, it's probably wrong.
Rule 2: All Loops Must Have Fixed Bounds
NASA's Rule: Every loop must have a compile-time verifiable upper limit on iterations. No unbounded while loops or loops that depend on external conditions.
What This Means:
Code should never contain loops that could theoretically run forever. Every loop must have a guaranteed exit point.
Why It Matters for Business:
Infinite loops are one of the most common causes of:
- Application freezes
- Server crashes
- CPU spikes that slow entire systems
- Runaway cloud computing costs
A loop that works perfectly for months can suddenly hang forever because:
- An API returns unexpected data
- A database query returns zero results
- A third-party service changes its behavior
- A sensor or input device malfunctions
Real-World Example:
A retail company's inventory sync ran in a while loop waiting for "all items processed." One day, a data corruption issue meant the "all processed" flag never triggered. The loop ran for 72 hours, consuming server resources, slowing the entire platform, and running up a $40,000 cloud computing bill before anyone noticed.
The Principle: Every operation should have a clear endpoint, with explicit handling for what happens if things don't go as planned.
Rule 3: No Dynamic Memory Allocation After Startup
NASA's Rule: Do not use dynamic memory allocation after initialization.
What This Means:
All the memory your program needs should be allocated when it starts. No requesting additional memory while running.
Why It Matters for Business:
This rule is stricter than most business applications require, but the principle is gold: don't introduce uncertainty at runtime.
Dynamic memory issues cause:
- Memory leaks that slowly degrade performance
- Allocation failures during peak load
- Unpredictable behavior under stress
- Crashes that are nearly impossible to reproduce
The Business Principle:
Systems should be predictable. If your application works fine with 100 users but mysteriously crashes with 1,000, you have a runtime uncertainty problem.
Application for Modern Software:
- Load test with realistic (and beyond realistic) data volumes
- Monitor memory usage in production
- Set hard limits on resource consumption
- Design for graceful degradation under stress
Rule 4: Keep Functions Short—60 Lines Maximum
NASA's Rule: No function should be longer than what fits on a single printed page—approximately 60 lines of code.
What This Means:
Functions should be short, focused, and do one thing well.
Why It Matters for Business:
Long functions are:
- Harder to test — more paths mean more test cases
- Harder to understand — readers lose context scrolling through hundreds of lines
- Harder to reuse — monolithic functions can't be broken apart
- Harder to debug — finding the problem requires reading everything
The 60-Line Challenge:
If a function can't fit on one screen, something is wrong. Either:
- It's doing too many things (split it up)
- It contains repeated logic (extract common patterns)
- It has unnecessary complexity (simplify)
Business Impact:
Code review studies consistently show that defect density increases with function length. Shorter functions have fewer bugs, and the bugs they do have are easier to find and fix.
The Principle: If you can't explain what a function does in one sentence, it's doing too much.
Rule 5: Use Defensive Checks Everywhere
NASA's Rule: Each function should contain at least two assertions—defensive checks that verify assumptions.
What This Means:
Don't assume. Verify. At every step, check that reality matches expectations.
Why It Matters for Business:
Defensive programming catches problems before they cascade. Instead of a silent corruption that surfaces weeks later, you get an immediate alert at the point of failure.
Defensive Checks Should Verify:
- Input parameters are valid
- Data is within expected ranges
- External responses match expected formats
- State is consistent before and after operations
- Resources are available before attempting to use them
Real-World Example:
A financial services firm processed transactions assuming all amounts would be positive numbers. When a data import bug introduced negative values, the system didn't crash—it silently processed "negative" transactions for three days, creating accounting discrepancies that took weeks to untangle.
A simple defensive check (if amount <= 0, reject and alert) would have caught this immediately.
The Principle: Write code as if everything external is trying to break your system—because eventually, something will.
Rule 6: Minimize Variable Scope
NASA's Rule: Declare all data objects at the smallest possible level of scope.
What This Means:
Variables should exist only where they're needed. If a variable is only used inside one function, declare it inside that function. If it's only used inside a loop, declare it inside that loop.
Why It Matters for Business:
Global or widely-scoped variables create hidden connections throughout code. Change one thing, break something seemingly unrelated.
Broad scope causes:
- Unexpected interactions between components
- Race conditions in concurrent systems
- Difficulty tracking where values are modified
- Challenges in testing (too many things affect outcomes)
The Business Impact:
A study of production incidents found that 30% of bugs involved unintended variable modifications—code that changed values it shouldn't have been able to access.
The Principle: Information should be on a need-to-know basis—for humans and for code.
Rule 7: Check All Return Values
NASA's Rule: Always check the validity of all function return values and parameters.
What This Means:
If a function returns a value, something should check it. If a function can fail, something should handle that failure.
Why It Matters for Business:
Ignored return values are like ignored warning lights. The information is there—you're just choosing not to look at it.
Common Failures from Ignored Returns:
- File operations that silently fail, leaving data unwritten
- API calls that error without triggering retry logic
- Database queries that return nothing, processed as if successful
- Authentication checks that fail but don't prevent access
Real-World Example:
A logistics company's tracking update function returned a success/failure status. The calling code ignored it. When the tracking database went read-only during a backup, updates silently failed for four hours. Customers saw outdated tracking while packages moved without visibility.
The Principle: If something tells you it failed, listen.
Rule 8: Limit Use of Pre-processor Directives (Avoid Tricks)
NASA's Rule: Use of macros and pre-processor directives should be minimal—no text substitution tricks that bypass normal code rules.
What This Means (For Non-C Developers):
Avoid "magic" that circumvents your language's normal rules and safety checks.
Why It Matters for Business:
Every programming language has ways to "work around" its safety features. These shortcuts might save time initially but create hidden risks:
- Code that looks like one thing but does another
- Behavior that changes based on hidden configuration
- Logic that bypasses type checking or validation
- "Features" that only work in specific environments
Modern Examples:
- Overriding security middleware "just for testing"
- Environment variables that change application behavior in undocumented ways
- Monkey-patching libraries to work around bugs
- Dynamic code execution (eval, exec) for flexibility
The Principle: If you're bypassing the safety rails, you should be very sure about why—and document it extensively.
Rule 9: Restrict Pointer Usage (Limit Indirection)
NASA's Rule: The use of pointers must be restricted. No more than one level of dereferencing.
What This Means:
Limit complexity in how code references data. Avoid chains of references that are hard to trace.
Why It Matters for Business:
While pointer-specific issues are less common in modern languages, the principle applies broadly: limit indirection and complexity in data access.
Modern Equivalents:
- Deeply nested object access (
order.customer.address.city.zipCode) - Long chains of service calls to retrieve related data
- Complex ORM relationships that generate unpredictable queries
- Event chains where A triggers B triggers C triggers D
The Business Impact:
Each level of indirection is:
- A potential null/undefined error
- A performance bottleneck
- A debugging nightmare
- A coupling between components
The Principle: The shortest path to data is usually the safest path.
Rule 10: Compile with All Warnings—And Fix Them
NASA's Rule: All code must compile with all warnings enabled at the most strict setting. All warnings must be addressed.
What This Means:
Don't ignore warnings. They're not suggestions—they're early indicators of potential problems.
Why It Matters for Business:
Warnings are the canary in the coal mine. They catch:
- Unused code that might indicate incomplete implementations
- Type mismatches that could cause runtime errors
- Deprecated function usage that will break in future updates
- Potential security vulnerabilities
- Logic that "works" but probably doesn't do what was intended
The Warning Problem:
Most projects accumulate warnings over time. Once there are 50 warnings, nobody notices when #51 appears—even if #51 is critical.
Real-World Example:
A SaaS company had 347 warnings in their build process. When a security vulnerability warning appeared among them, it was ignored for months. The vulnerability was eventually exploited, resulting in a data breach affecting 50,000 customers.
Zero Warning Policy:
NASA requires zero warnings. Every warning must be fixed or explicitly documented as acceptable. This means new warnings are immediately visible and addressed.
The Principle: Today's warning is tomorrow's production incident.
The Mars Rover Lesson: State Machines and Explicitness
NASA's Mars rovers use a state machine architecture—a design pattern where every possible state and transition is explicitly defined.
The rover is always in one known state:
- Idle
- Navigate
- Analyze
- Sample
- Transmit
- Safe Mode
Every transition between states has explicit conditions:
- What triggers the transition?
- What happens if the transition fails?
- What state do we revert to on error?
Why This Matters:
With a state machine, engineers can:
- Simulate every possible scenario
- Prove the system won't get stuck
- Test failure recovery explicitly
- Understand exactly what the system is doing at any moment
For Business Software:
Critical workflows benefit from state machine thinking:
- Order processing (placed → paid → shipped → delivered)
- User authentication (anonymous → authenticated → authorized)
- Payment processing (initiated → pending → confirmed → settled)
When each state is explicit, edge cases are visible and handleable rather than hidden and dangerous.
Applying NASA's Rules to Your Organization
You don't need spacecraft to benefit from these principles. Here's how to apply them:
For Technical Leaders (CTOs, Engineering Managers)
1. Establish Clear Standards
- Document coding standards based on these principles
- Make them part of onboarding for new developers
- Include them in code review checklists
2. Enforce Through Tooling
- Configure linters to catch complexity
- Set up static analysis for potential issues
- Require zero warnings in CI/CD pipelines
3. Measure and Track
- Monitor code complexity metrics
- Track bug density by module
- Review incidents for pattern violations
For Business Leaders (CEOs, COOs)
1. Invest in Quality
- Budget time for code review and refactoring
- Don't pressure teams to skip testing for deadlines
- Recognize that "faster" now often means "broken" later
2. Ask the Right Questions
- "What's our warning count?" (Should be zero)
- "How long are our functions on average?" (Should be short)
- "What happens if external service fails?" (Should have clear answers)
3. Understand the Trade-offs
- Quick fixes create technical debt
- Clever solutions create maintenance burden
- Skipped tests create future outages
For Development Teams
1. Embrace Simplicity
- If you're proud of how clever your code is, refactor it
- If someone can't understand it in 5 minutes, simplify it
- If it needs extensive comments to explain, restructure it
2. Be Defensively Paranoid
- Check every input
- Validate every response
- Handle every error case
3. Think Long-Term
- You will read this code again in 6 months
- Someone else will maintain this after you leave
- The "temporary" workaround will become permanent
The Cost of Ignoring These Rules
Software failures have real business consequences:
| Incident Type | Typical Cause | Business Impact |
|---|---|---|
| Outage | Unhandled error, infinite loop | Lost revenue, customer trust |
| Data corruption | Ignored return values, race conditions | Legal liability, cleanup costs |
| Security breach | Bypassed checks, ignored warnings | Regulatory fines, reputation damage |
| Performance degradation | Memory leaks, unbound operations | Customer churn, increased costs |
| Failed deployment | Untested edge cases | Rollback costs, delayed features |
The average cost of downtime for enterprises is $5,600 per minute. A single hour of outage can exceed $300,000 in direct costs—before counting reputation damage.
Summary: The Power of 10 for Business
| # | NASA's Rule | Business Principle |
|---|---|---|
| 1 | Simple control flow | Simplicity over cleverness |
| 2 | Bounded loops | Every operation has a guaranteed endpoint |
| 3 | No runtime memory allocation | Don't introduce uncertainty at runtime |
| 4 | Short functions (60 lines) | One function, one purpose |
| 5 | Defensive assertions | Verify assumptions constantly |
| 6 | Minimal variable scope | Information on a need-to-know basis |
| 7 | Check all return values | Listen when systems tell you they failed |
| 8 | Avoid preprocessor tricks | Don't bypass safety mechanisms |
| 9 | Limit pointer/indirection | Shortest path to data is safest |
| 10 | Zero warnings | Today's warning is tomorrow's incident |
Conclusion: Building Software That Doesn't Fail
NASA's "Power of 10" rules aren't just for rocket scientists. They represent fundamental principles of reliable software that apply whether you're landing on Mars or processing customer orders.
The common thread through all 10 rules is this: predictability over cleverness, explicitness over assumption, simplicity over sophistication.
Your business may not be sending rovers to Mars, but you're still betting on your software. Every transaction, every customer interaction, every business process depends on code working correctly.
The question isn't whether to apply these principles—it's how quickly you can start.
Frequently Asked Questions
What is NASA's "Power of 10"?
The Power of 10 is a set of 10 coding rules published by NASA's Jet Propulsion Laboratory in 2006. These rules were designed to ensure that software controlling spacecraft—where failures can mean losing billion-dollar missions—is as reliable as possible. The rules focus on simplicity, predictability, and defensive coding practices.
Are these rules only for C programming?
The original rules were written for C, which is commonly used in embedded systems and spacecraft. However, the principles apply to any programming language. Concepts like keeping functions short, checking return values, and avoiding excessive complexity are universal best practices.
Isn't following all these rules slower for development?
Initially, yes—defensive coding requires more thought and more code. However, studies consistently show that time invested in code quality pays back 10x or more in reduced debugging, fewer production incidents, and easier maintenance. The "fast" approach usually just shifts costs to later (and more expensive) stages.
How do we start implementing these in our organization?
Start with the easiest wins: enable all compiler/linter warnings and commit to fixing them. Then gradually introduce code review checklists based on these rules. Focus on new code first—don't try to refactor everything at once. Measure progress through metrics like warning counts, average function length, and incident frequency.
Do modern frameworks and languages make these rules obsolete?
Modern languages address some issues (like memory management in garbage-collected languages), but most of these rules remain highly relevant. Complexity, ignored errors, excessive scope, and unbounded operations are problems in every language and framework.
What if our developers resist these rules as too restrictive?
Focus on the "why" behind each rule with concrete examples of failures. Most experienced developers have war stories about debugging complex code or tracking down ignored error cases. Frame the rules as protection for developers (easier debugging, fewer 2 AM calls) rather than just restrictions.
Ready to Build More Reliable Software?
Every production incident, every outage, every "how did this bug make it to production?" moment has roots in violations of these basic principles.
NASA figured this out because they had no choice—failure wasn't an option. Your business might survive software failures, but why accept the cost when proven solutions exist?
Here's How DSRPT Can Help:
🔍 Code Quality Assessment We'll audit your codebase against these principles and identify the highest-risk areas—before they become production incidents.
🛠️ Technical Leadership Consulting Strategic guidance for CTOs and engineering leaders on building quality-focused development cultures that prevent problems rather than just fixing them.
💬 Quick Question? Not sure where to start? Send us a message about your specific challenges.
Why DSRPT?
We build software for businesses across Kuwait, the GCC, and Australia—and we hold ourselves to these same standards. As Google Premier Partners with deep technical expertise, we understand that great software isn't just about features—it's about reliability, maintainability, and trust.
Software that works is table stakes. Software that keeps working—under pressure, at scale, over time—is what separates successful businesses from the rest.