A Look into NASA’s Coding Philosophy
Having done work for Kennedy does not imply I’m NASA’s mouthpiece. This write-up was made at a personal capacity, and came from a live talk I gave on Twitch.
Who, out of all of us, speaks the truth?
The World of Modern Software
There’s a recurring theme in the programming community that’s tied to finding “better ways” to write “modern software.” Whether or not the term “modern” is actually any useful — computer programming hasn’t been around for very long — I’m definitely left with the impression folks always have something “new” or “better” to say on the subject. And so if we pay attention to the conversations surrounding software development today, we’ll quickly realize how important it is to separate the wheat from the chaff: what’s useful and what isn’t.
NASA has to Cut through the Bullshit
Given all of this modern software talk, I have seen beginner programmers asking what I think is the most important question of their careers: “Which things should we pay attention to?”, and honestly, it’s generally quite cruel to encourage them to follow that up with:
- Should OOP be the future of programming?
- Let’s join the Rust Evangelism Strikeforce LUL
- Is Go like totally better than
<language_with_other_design_goals>?
At least, that’s not how NASA set out to answer it when it had asked that question too. The story of the agency is well-known, which is that the space program may suffer irreversible consequences if any of its software is incorrect, among them death. The shock of that reality has allowed them to develop a certain attitude towards programming. It could be instructive to take a look at what they value.
With some years of work there, I wish to provide a first-hand account on the philosophy that’s allowed the space agency to produce some of the world’s most reliable software, and I’ll frame their attitude towards programming with a set of four assumptions I think they make for programmers in the workforce (and which I have experienced directly.)
NASA’s Four Assumptions
You will have Access to a Mentor
“Who’s your mentor?” is a common ice-breaker with any pair of sweaty NASA programmers avoiding eye contact, and it’s thanks to the agency’s commitment to making sure each programmer can have a mentor. It could be at the level of business, with the OSBP’s Mentor-Protégé program, the internal NEXT project, or with the Pathways Agency Cross-Center Connection (PAXC). Interestingly, you don’t need to go out of your way to get access to one, because we’re all assigned personal mentors from the very beginning. The idea that a programmer can’t have someone capable and with senior experience to overlook their individual progress is close to horrifying for the space program.
We Trust Each Other’s Potential
There’s a reasonable degree of trust when entering the workforce due to the federal background investigations you’re subjected to. It is also assumed, however, that everyone has something valuable to offer, and we trust the potential of the individual. Show that you’re good and the title becomes almost meaningless. It’s not uncommon for an intern to contribute to high-profile NASA software projects.
You’ll Say “I Don’t Understand”
This statement is thrown around left-and-right. You will have knowledgeable senior developers asking interns “I don’t understand this part of the codebase. Is that a language feature I don’t know about yet?” or management asking engineers “I’m not sure what the implications of your work today are. Could we go over it a few times until I have a good grasp of it?” These questions are at the core of their daily work routine.
We Value Insights into how Computer Systems Operate
NASA hungrily searches for insights into how computers work, and they find value in discovering fundamental system limitations to prevent backing into bad software development decisions.
Consider Gene Amdahl. He was an early computer pioneer with an interesting inquiry: what’s the effectiveness of improving one component of a system? Say that fifty percent of your program’s running time was improved by a factor of four (wow!) and now we want to know how fast the application is. In other words, something took time T1 to run to completion, and now a part of that something (which takes some fraction f from T1) is k times faster. I’ll spare you any math, although it’s very simple — define the new time T2 using T1, f, k, and express the relative performance increase as a ratio of T1 and T2. You’ll end up with the following equation:
Let Amdahl’s Law sink in... Going with the earlier example, to know how fast your application is now simply apply the formula:
This gives 1.6. Though you took half of your entire program, and optimized it to be four times faster, the overall system is only 1.6x faster. Let’s shock ourselves further. Say you take some other component and the time it takes to run it is now zero (k tends to infinity). You get a special case of Amdahl’s Law:
Assume that component comprises 60% of your program’s running time, and it now takes effectively no time to run it. The theoretical maximum speedup is 2.5… Amdahl’s Law is telling us that to significantly improve the speed of a system, we’ll have to improve a very large fraction of it. Simple truth, but easily forgotten. The law is used often in parallel computing to predict speedups using multicore processors, and Julian Browne reformulates it in that context: “Essentially the law states that whilst a process can be decomposed into steps which may then be run in parallel, the time taken for the whole process will be significantly limited by the steps that remain serialised.” (source)
With these assumptions in mind, the rest of the article gives a more personal view on what lessons could be gleaned from them.
Avoid Unreliable Sources of Knowledge
Some of my friends agree the programming profession hasn’t matured yet because it’s at a pre-scientific stage of its existence. I claim many of us are subconsciously subscribing to traditional sources of knowledge that have proven to be unreliable, and as far as I can tell NASA has done well to guard themselves against them:
Faith
I don’t mean faith in the sense of hope. Faith is also used when we want to believe in something with no good reason to believe in it:
Lead: “I like our app’s new features for our customers, and you said you downloaded a library to write them?”
Junior: “Yeah. It’s worked fine so far.”
Lead: “Is it open source? Otherwise who is the vendor and how good are they on support? Have you proven it to be robust and tested it across our parameter space?”
Junior: “No but I’ve been using it for a while and it hasn’t caused any issues.”
Lead: *PLONK*
This happens not just for random downloads, but when your code wasn’t working but then it magically did and you decide to call it a day. It may be difficult to notice when someone is relying on faith to decide how good their software is, but if it drags on long enough it will lead to slow and buggy software.
Revelation
I mean revelation when a figure of authority reveals something as incontrovertibly true, or some fact has been passed down from earlier times, and you believe it to be true because it has been believed to be true. If you tie it with the need for people to identify with some random subset of the programming community, it’s the root cause of heated arguments about which text editor reigns supreme, and how much your use of one language makes you a real programmer.
Charisma
The conference is packed with an atmosphere of euphoria; excitement for what’s to come as the next framework is announced. A passionate author comes to the stage with a singing voice. The talk and powerpoint slides discuss the newest principles that promise bullet-proof programming practices — of the kind that’ll make you the 10x programmer (for real this time!). With a natural ability to work the crowd, and the official setting in which the author talks, it can be hard to realize we’ve come to believe the author’s claims. And most importantly buying their book.
Glow
I realize it’s a weird word to use, but when an idea is compelling and exciting enough it just seems to give off a certain “glow.” It is shiny and it must therefore be true.
We could go on, but moving away from this kind of list is what it means to be scientific about our technological progress.
Expand Your Computer Literacy
A conversation about the nature of the universe is generally more useful when those talking are scientifically literate. Similarly, a discussion on programming benefits from everyone reaching a certain threshold in computer literacy. Indeed, there are enduring ideas giving life to computer systems, and programmers ought to value them. If we call ourselves professionals, we have a real responsibility to learn the underlying concepts behind computers. It protects us from unreliable sources of knowledge, and it shows us the things we should pay attention to. NASA realized this, and has made sure the organization’s culture allows for everyone’s literacy to skyrocket.
Recommendations
Did any of this resonate? Are you a programmer looking to improve your computer literacy? If so I have a couple of personal suggestions.
Computer Systems: A Programmer’s Perspective
Computer System’s: A Programmer’s Perspective was very formative in my career, and if it matters, it is my favorite programming book. The topics covered here are the kind of foundations I think everyone should have. At the very least, a thorough study of Chapters 1–3, the memory hierarchy, and System I/O are eye-opening. If you are working on anything web-related, of course the chapter on Network Programming is relevant.
Finding Like-Minded People
There’s a small community called Handmade Network, with an incredible team (spoiler: I’m part of the team) as we try to build a place where we can step away from the modern software conversation, and instead talk about the things I have laid out here. We are as vulnerable as other communities to fall into dogma (and we have in the past), but we try to be cognizant of it.
The community also has interviews with well-known programmers discussing the state of affairs, whether or not they agree with our conclusions. Previous ones are available here.
Related Press
- Reddit (2017)
- KillScreen Op-ed (2016)
- Hacker News (2015)
- Reddit (2015)
- JAXenter (German) (2015)
About the Author
2017 marked three years of work at Kennedy Space Center, writing and maintaining launch control system software. I was awarded Kennedy’s Intern of the Year by 2015 which lead me to NASA’s Pathways program, where I got tasked to research ways to simplify the debugging of (wait for it) flying space robots. The fruit of that work landed me on Kennedy’s 2016 Top 10 list of Innovators — though just barely!
Most of my work is unfortunately SBU so it may not be disclosed online. I technically could, but I’ve been told federal prison does not have chocolate wine. So no dice. You can find me over at Twitter, Twitch, or e-mail.
