Overcomplicating Things Is So Easy
Maciej CegĆowski writing about âThe Lunacy of Artemisâ:
You donât have to be a rocket scientist to wonder whatâs going on here. If we can put a man on the moon, then why can't we just go do it again? The moon hasnât changed since the 1960âs, while every technology we used to get there has seen staggering advances. It took NASA eight years to go from nothing to a moon landing at the dawn of the Space Age. But today, twenty years and $93 billion after the space agency announced our return to the moon, the goal seems as far out of reach as ever.
Sounds like vaporware: lots of money and time invested, but little progress made towards your goal.
Advocates for Artemis insist that the program is more than Apollo 2.0. But as weâll see, Artemis can't even measure up to Apollo 1.0. It costs more, does less, flies less frequently, and exposes crews to risks that the steely-eyed missile men of the Apollo era found unacceptable.
Sounds typical of software going from version 1.0 to 2.0 đ„
But seriously, there are a lot of parallels in this piece to making software. Like how 2.0 is touted as the ânew and improvedâ and yet it often canât reliably do what 1.0 did:
even that upgrade wonât give SLS the power of the Saturn V. For whatever reason, NASA designed its first heavy launcher in forty years to be unable to fly the simple, proven architecture of the Apollo missions.
Again, the parallels to software are uncanny. Not just the technical problems, but the people ones too:
But to search for technical grounds is to misunderstand the purpose of Gateway. The station is not being built to shelter astronauts in the harsh environment of space, but to protect Artemis in the harsh environment of Congress.
Keeping stakeholders happy, fighting for funding, sound familiar?
This all really goes to show how keeping things simple (and boring) is really hard:
Itâs instructive to compare the HLS approach to the design philosophy on Apollo. Engineers on that program were motivated by terror; no one wanted to make the mistake that would leave astronauts stranded on the moon. The weapon they used to knock down risk was simplicity. The Lunar Module was a small metal box with a wide stance, built low enough so that the astronauts only needed to climb down a short ladder. The bottom half of the LM was a descent stage that completely covered the ascent rocket (a design that showed its value on Apollo 15, when one of the descent engines got smushed by a rock). And that ascent rocket, the most important piece of hardware in the lander, was a caveman design intentionally made so primitive that it would struggle to find ways to fail.
What technologies or tools make you think of that phrase â âa design so primitive, it struggles to find ways to failâ? (HTML & CSS might I suggest?) I would love if more of my digital tools and services employed this ethos.
But modern tools (and space hardware, apparently) seemingly go in the opposite direction. They go out of their way to create problems that can be solved with technology.
On Artemis, it's the other way around: the more hazardous the mission phase, the more complex the hardware.
As Devine noted about computing, perhaps we havenât even scratched the surface of what can be done with little.
Apollo showed us that.