[HN Gopher] NASA has a list of 10 rules for software development
___________________________________________________________________
NASA has a list of 10 rules for software development
Author : vyrotek
Score : 56 points
Date : 2025-02-15 20:24 UTC (2 hours ago)
(HTM) web link (www.cs.otago.ac.nz)
(TXT) w3m dump (www.cs.otago.ac.nz)
| jmclnx wrote:
| nice, saved because these days who know ho long the page will be
| available :)
| readthenotes1 wrote:
| Someone in NASA once told me that it was easier to teach a
| mechanical engineer to program then a software developer
| mechanical engineering.
|
| From that perspective, the avoidance of recursion is more
| compelling. Plus, Fortran didn't support it...
| paulluuk wrote:
| I'm curious, how does that perspective make the avoidance of
| recursion more compelling?
| dooglius wrote:
| Title should indicate that this is a _criticism_ of the rules.
| killingtime74 wrote:
| It's more like a commentary
| Enginerrrd wrote:
| Yeah and also one that I'm not very impressed with.
|
| The criticism is (mostly) super contrived and totally misses
| the wisdom behind why some of these rules were made in the
| first place. A lot of the author's points are very reminiscent
| of the same classic rebuttal against criticisms of the C
| language for being insecure: "It's perfectly fine if you're
| good and don't make stupid mistakes." That's just not a very
| mature view of working with groups of human beings.
|
| Most of these rules are designed to reduce errors that are
| difficult for humans to see by making the code more readable,
| deterministic, and avoiding situations that can lead to
| unintended behavior that is subtle in its true complexity.
| Creating a series of "Gotchas" where it perhaps negates that
| idea in an obscure situation doesn't really mean that the rules
| don't tend to produce code that is more reliable and auditable.
|
| Some of these rules really do seem kind of anachronistic,
| but... then again there's still a lot of old FORTRAN code and
| the like running on NASA hardware.
| einpoklum wrote:
| Well, I was expecting to see:
|
| _Rule 1: Don 't write any code that can make the ship go ka-
| boom._
|
| _Rule 2: We need to consistently use the f 'ing metric system
| and SI units - and don't you forget it._
|
| _Rule 3: ... You haven 't already forgotten about rule #2, have
| you?_
| shwoopdiwoop wrote:
| What's wrong with using the metric system?
| Swizec wrote:
| Is a reference to this famous incident of a mars lander
| slamming into mars due to mismatched units.
|
| https://everydayastronaut.com/mars-climate-orbiter/
| kanbankaren wrote:
| Not sure whether they used a value pattern.
|
| typedef struct { float value; } meter;
|
| typedef struct { float value; } feet;
|
| Using strong typing, you can avoid passing values in wrong
| units.
| naturlich0 wrote:
| Nothing lol but people tend to be obnoxious about using it
| marcosdumay wrote:
| NASA often forget they use it.
| nealabq wrote:
| No recursion means no Erlang. Which means no RabbitMQ?
| AlotOfReading wrote:
| Erlang seems like a strange choice for deeply embedded hard
| realtime systems that aren't supposed to ever crash. It's a
| different set of tradeoffs than Erlang makes.
| PaulRobinson wrote:
| Erlang was designed for running telephone exchanges - about
| as deeply embedded hard realtime a system as you can get,
| that needs to be fault tolerant otherwise 911 goes down.
| AlotOfReading wrote:
| Erlang is typically used for _soft_ realtime systems on
| fairly powerful non-embedded hardware. There have been
| attempts to use it in hard realtime systems, but no
| successful ones that I 'm aware of.
| toolslive wrote:
| from the original document: "critical code is written in C." The
| document is not dated, but it's probably quite old (I'm guessing
| 30-something years). Writing critical code in C is probably a
| mistake, but once you find yourself in that situation, you will
| find these rules are too tight (which is also what the criticism
| is about). You should probably read them as "try to avoid ...".
|
| So I would just prepend the document with "Rule 0: Try to avoid
| writing critical code in C."
| zoogeny wrote:
| > People using Ada, Pascal (Delphi), JavaScript, or functional
| languages should also declare types and functions as locally as
| possible.
|
| My own personal approach in JavaScript is to avoid defining
| functions in a nested manner unless I explicitly want to capture
| a value from the enclosing scope.
|
| This is probably due to an outdated mental model I had where it
| was shown in performance profiling that a function would be
| redefined every time the enclosing function was called. I doubt
| this is how any reasonable modern JavaScript interpreter works
| although I haven't kept up. Since the introduction of arrow
| functions (a long time ago now in relative terms) their prolific
| use has probably lead to deep optimizations that render this old
| mental model completely useless.
|
| But old habits dies hard I guess and now I keep any named
| function that does not capture local variables at a file/module
| scope.
|
| A lot of the other notes are interesting and very nit-picky in
| the "technically correct is the best kind of correct" way that
| older engineers eat up. I feel the general tone of carefulness
| that the NASA rules is trying to communicate to be very good and
| I would support most of them in the context that they are
| enforced.
| Gibbon1 wrote:
| I use gcc's nested functions a fair amount. Because it reduces
| cutting pasting and makes the code much easier to understand.
|
| I use variable argument macro's to implement debug print
| functions for debugging. And I just leave them in the code as a
| form of documentation. Looking at the debug print statements
| tells you a lot of about what the code is doing.
| shambulatron wrote:
| He is the odd
| jsrcout wrote:
| I work with a lot of embedded and embedded-adjacent software, and
| even I think several of these rules are too much. Having said
| that, Holzmann's rules are from 2006, and embedded / space
| qualified hardware has improved quite a bit since then. These
| days planetary probes run C++, and JWST even uses JavaScript to
| run command scripts. Things are changing.
| raylus wrote:
| Note this is NASA/JPL, not NASA-wide, JPL is a NASA center
| (FFRDC).
| matu3ba wrote:
| Example 1 is a deficit of C with missing computed goto and switch
| continue. Example 2 review is ambiguous on practicality. Example
| 3 reads very odd, an over-approximated upper stack bound is very
| possible
| https://github.com/ziglang/zig/issues/157#issuecomment-76395...
| and tighter computation with advanced analysis as well. Example
| 4,5,6,7,8,9,10 yes. Overall good read.
| layer8 wrote:
| The rule about recursion is likely also to ensure a statically
| known bound on needed stack space, in addition to a statically
| known runtime bound (in conjunction with the other rules).
|
| While the criticism of rule 3 is right in that there is a
| dependence on the compiler, it is still a prerequisite for
| deriving upper bounds for the runtime by static analysis on the
| binary. This is actually something that is done for safety-
| critical systems that require a guaranteed response time, based
| on the known timing characteristics of the targeted
| microprocessor.
| ajross wrote:
| > The rule about recursion is likely also to ensure a
| statically known bound on needed stack space
|
| It's definitely that. Static stack size analysis in the
| embedded world is a long-standing paradigm and recursion and
| function pointer indirection defeat that.
|
| If the point of rule was that NASA was arguing that recursive
| constructions are always harder to reason about than iterative
| ones, then obviously NASA is wrong.
| AndyKelley wrote:
| If I made my own criticism of these rules it would be very
| different from OP. It was difficult to take the article serious
| from the get-go when it defended setjmp/longjump. That pattern is
| so obviously broken from anyone who has ever had to go near it.
| The article makes an argument like this:
|
| 1. setjmp/longjmp is exception handling
|
| 2. exception handling is good
|
| and I take serious issue with that second premise.
|
| Also the loop thing obviously means to put a max iteration count
| on every loop like this:
|
| for (0..N) |_| {
|
| }
|
| where N is a statically determined max iteration count. The 10^90
| thing is silly and irrelevant. I didn't read the article past
| this point.
|
| If I were to criticize those rules, I'd focus on these points:
|
| * function body length does not correlate to simplicity of
| understanding, or if anything it correlates in the opposite way
| the rules imply
|
| * 2 assertions is completely arbitrary, it should assert
| everything assertable, and sometimes there won't be 2 assertable
| things
| dehrmann wrote:
| Friendly reminder that you are most likely not NASA and have
| different goals, so you should approach the problem differently.
| The cost of a stack overflow (even at FAANG-scale) for you is
| likely many orders of magnitude cheaper than for NASA, and the
| cost of delaying a project for a year is much worse.
|
| Unless you work on commercial aircraft avionics. NASA flying a
| probe into Mars makes them look dumb. Flying an aircraft into a
| mountain haunts people for the rest of their lives.
| bumby wrote:
| Just for context, these aren't really "rules" as much as proposed
| practices. Note that official "rules" are in documents with names
| like "NPR" aka "NASA procedural requirements." So, while someone
| may use the document in the featured article to frame a
| discussion, a developer is not bound to comply (or alternatively
| waive) those "rules" and could conceivably just dismiss them.
| manmal wrote:
| > All loops must have a fixed upper-bound
|
| Things like spinlocks or CAS (Compare-And-Swap) are elegant and
| safe solutions for concurrency, and AFAIK you can't really limit
| their upper bound. Others in the thread have pointed out that
| those are more guidelines than rules - still, not sure about this
| one.
___________________________________________________________________
(page generated 2025-02-15 23:00 UTC)