Excellence Is a Habit

ELI5 / TLDR

NASA didn’t land on the Moon by being brilliant once — they flew 25 manned missions in nine years, each one building muscle memory for the next. The author argues software teams should work the same way: automate deployments until they’re boring, run disaster drills until recovery is reflex, and accept that toilets will break in space. Excellence is what happens when you’ve done the thing so many times that the hard version looks routine.

The Full Story

The Quote That Isn’t Quite Aristotle

Will Durant wrote “We are what we repeatedly do. Excellence, then, is not an act, but a habit” — a clean paraphrase of Aristotle that’s been misattributed to the philosopher himself ever since. The author uses it as a frame for connecting NASA’s lunar history to modern engineering practice.

Twenty-Five Missions in Nine Years

Mercury, Gemini, Apollo — each program layered on the last. Between May 1961 and April 1970, NASA launched 25 crewed missions at a pace of one every four to five months, accelerating to every one to two months during 1965-66. That cadence wasn’t reckless. It was deliberate repetition. By the time Apollo 11 landed, the people in Mission Control had already rehearsed every conceivable failure mode across dozens of prior flights. Apollo 13’s famous recovery wasn’t improvisation — it was pattern-matching against thousands of hours of practice.

Artemis II and the Fifty-Year Gap

The Artemis II crew just returned from lunar vicinity, the first humans near the Moon in over half a century. The timing lines up with the 56th anniversary of Apollo 13’s launch. Fifty years is a long time to let muscles atrophy, and the mission surfaced two instructive glitches.

First, an abort system sensor flagged dangerously high temperatures during launch. Turned out the sensor itself was broken, not the thing it was measuring. Monitoring is only useful if you understand the difference between a real signal and a noisy instrument — a lesson any on-call engineer has learned at 3 a.m.

Second, the toilet failed. Astronauts and ground engineers had to troubleshoot a repair in real time. The system degraded gracefully rather than catastrophically. Slower beats dead.

The Software Parallel

The author draws a straight line from NASA’s playbook to DevOps. Continuous delivery automates deployments until shipping code is unremarkable. Infrastructure-as-code makes environments reproducible and disposable. Chaos engineering — deliberately breaking things in production — is the software equivalent of NASA running failure simulations before every launch. The point isn’t to prevent all failures. It’s to make recovery a reflex.

Claude’s Take

Solid analogy, competently drawn. The NASA-to-DevOps pipeline isn’t new territory — “treat deploys like launches” has been a conference-talk staple for a decade — but the Artemis II details give it a fresh hook. The sensor-versus-signal point about monitoring is genuinely useful; too many teams drown in alerts without distinguishing instrument failure from actual incidents.

Where it thins out: the article gestures at chaos engineering and disaster recovery drills without much specificity. No examples of teams that actually run these well, no mention of what it costs to build that culture, no acknowledgment that most organizations can’t sustain NASA-level cadence because they’re not NASA. It reads more like a well-structured blog post than a deep argument.

Score: 6/10. Clear writing, decent historical detail, but the software lessons stay at the bumper-sticker level. You’ll nod along and forget it by Thursday.