Ever wonder why we could write software to get to the moon, but not to count votes? Here are 5 reasons
The uproar after the Iowa Democratic Party caucus reporting software failed was a harsh reminder for programmers of how bad things can get. Counting
up a few simple votes isn’t as complicated as building an autonomous car, training an AI to recommend movies, or even updating a bank database safely, yet the programmers couldn’t pull this off. One particular damning tweet read, “Hard to believe we put men on the moon.”
The thing is that the comparison to flying to the moon isn’t really fair. Even though guiding the Apollo lander to the moon seems much harder than tabulating a few thousand votes, all of the extra work wrapped around the modern vote tally is what makes it much more complex.
Some parts are getting easier. The new so-called “serverless” option promises to let us write the most essential logic and be finished, but we’re not there yet. Sure, writing the functions is simpler, but the rest of the time we’re wrestling with configuration options. We spend hours writing hundreds of lines of YAML, spelling out decision after decision, but for some reason that isn’t considered “coding.”
Coding or not, all of this thinking adds up. The non-programmers won’t understand this—and I want them to understand the reasons offered as an explanation, not an excuse—but crafting software is dramatically more difficult and complicated today. Here are five reasons why.
Code was simpler then
The best way to get a feel for what NASA’s job was like is to read some of the code, now immortalized in a GitHub repository. Choose a file at random. GROUND_TRACKING_DETERMINATION_PROGRAM.agc, for instance, has 204 lines and more than 85 of them are comments. Each of the lines consists of only one operation, unlike modern languages, which can pack dozens of operations with multiple options into one line.
The simplicity becomes obvious as you page through the files. Even though the code looks impressive when it’s printed out and put in binders, as it is in the famous photo of Margaret Hamilton, there are only several hundred files and most of them are short and filled with comments. They had to be. The Apollo Guidance Computer had only 36k of ROM to hold the compiled version.
That meant the programmers could easily brush off feature requests and concentrate on only the most important steps.
The code itself will look positively inscrutable to most modern programmers because very few developers today learn to read assembly language or machine code. Even fewer learn to write it. While it looks quite cryptic, the semantics are much simpler. After all, the machine had just a few registers, some RAM, and some IF-THEN options for branching.
Compare these to the rules that modern programmers must master to handle abstractions like closures or recursive object data. The Java team is rolling out version 14 now, and every new version along the way came with clever new mechanisms to be grokked. Even ideas that are intended to make programming easier, like callback functions in JavaScript, require quite a bit of abstract thinking.
Once you figured out the cryptic instruction names of assembler, it was actually much easier and simpler to write.
[ Also on InfoWorld: 3 ways to kick off a devops program ]
Security was simpler
Yes, security was tight at NASA for the launch, but the programmers didn’t have to worry about writing code for a machine connected to the Internet. The Apollo Guidance Computer talked only to Houston, and only infrequently. Today, every smartphone is constantly interacting in the background with dozens of websites and services that might be secretly malicious.
This makes shipping code today a security nightmare. Deploying a basic container requires juggling a special file full of passwords and “secrets” that keep everything secure. Android and iOS app developers have to manage multiple secret keys for signing their app before it can be uploaded to the various stores. If any of these secrets slip out, anyone with a connection to the Internet might be able to break in and have their way with the machine.
The modern Internet is a cesspool of bad actors, and the spammers, clickjackers, and phishers are the nice ones. There are plenty of worse actors working serious cons and even—dramatic Hollywood pause—murder. Aside from the Soviet Luna 15, a craft rushed into space just three days before Apollo 11, the programmers back then didn’t have to worry about anyone else.
Function was the focus
Back then, there were no design committees pondering whether a button should be moved over a pixel or two. There were no splash screens, moving icons, background shading, or millions of fonts. Heck, IBM didn’t launch the Selectric with changeable fonts until 1961.
While a modern programmer can leverage nice standards like HTML, CSS, and SVG, and untold millions of lines of libraries like React or Vue, the same programmer must also live up to their standards. The astronauts were just happy that the little glowing vacuum tubes were still glowing. They didn’t care about the shade of green.
Fewer moving parts
Mechanical engineers tend to count the number of moving parts and use it as a proxy for the complexity. The Lunar Lander’s guidance computer had one very important job, tracking the position, and that’s about it. The modern smartphone does a bazillion things at the same time, many of which are taken for granted by an unthinking and uncaring populace of ingrates who will uninstall an app if it doesn’t respond in milliseconds.
All of this complexity adds up. Yes, automated build code, well-defined APIs, and endless libraries mean that programmers can let the magic elves in the continuous integration pipeline do most of the work, the complexity is still there. A Go app compiled with version 1.7 that only prints “Hello World” is 1.6 megabytes alone, and the Go world was totally thrilled with this news because it was 2.3 megabytes before.
Consider Isaac Newton’s line about standing on the shoulders of giants. Modern programming feels a bit like being on top of one of those human pyramids built by the most insane cheerleading teams. Sure, everyone below you is doing much of the heavy lifting, but just keeping your balance is a feat.
[ Also on InfoWorld: How to align test automation with agile and devops ]
Freedom from lawyers
According to my count, there are 22 thousand words in the basic Terms of Service for renting a machine in Amazon’s cloud. There is also an entirely different TOS for using the website to rent the machine. Then each individual product often has its own TOS, like this one for Activate. Add them up and they’re much longer than the 36 thousand instruction words in the ROM in the Lunar Lander’s computer.
The Apollo programmer didn’t know that the movie “Aliens” would come along with the tag line, “In Space, No One Can Hear You Scream,” but they understood the idea well and knew this meant that no ambulance chasing lawyer would hear you, either. And if the lawyers did get involved, the principle of sovereign immunity is a beautiful tool for brushing aside all of the legal hassles that confound modern programmers.
Related:
Peter Wayner is contributing editor at InfoWorld and the author of more than 16 books on diverse topics, including open source software, autonomous cars, privacy-enhanced computation, digital transactions, and steganography.