Famous Bugs
When Code Goes Wrong in Spectacular Fashion
These stories from Chapter 7 show what software bugs cost once they leave the lab and meet the world. They’re a reminder that precision in programming isn’t a box you tick to keep the marker happy. It matters, and once in a while it matters more than anything else in the room.
When Bugs Make History
Most bugs are minor irritants. You fix them, move on, forget they ever existed. But a rare few achieve a kind of dark immortality. They get taught to computer science students for decades, retold as warnings about what happens when an error slips its leash and wanders out into the world.
The Therac-25: When Code Has Consequences
In the 1980s, the Therac-25 was a radiation therapy machine controlled by software. Due to a race condition in the code, the machine occasionally delivered radiation doses hundreds of times stronger than intended. At least six patients received massive overdoses. Several died.
The bugs were the kind that hide well: race conditions that surfaced only when an operator typed one particular sequence of keystrokes at one particular speed. Easy to miss in testing. Unbearable in hindsight. The lesson is stark, and you should let it land: software runs physical machines now. A bug isn’t always just an inconvenience. Sometimes it is fatal.
The Mars Climate Orbiter: A Very Expensive Misunderstanding
In 1999, NASA lost a $327 million spacecraft because one team did the maths in metric and another did it in imperial. One piece of software spoke in pound-seconds; the piece listening expected newton-seconds. Each was perfectly correct on its own terms, which is exactly why nobody caught it. The two halves of the system were having different conversations and both were certain they were being clear. The orbiter arrived at Mars at the wrong altitude and burned up in the atmosphere, undone not by a hard sum but by an assumption nobody thought to say out loud.
The lesson: communication isn’t only between you and the computer. It runs between parts of a system, between teams, between assumptions nobody wrote down. Document your units. Check your interfaces. Assume nothing, especially the things that feel too obvious to mention, the way no one warns a guest which tap runs scalding.
The Morris Worm: Exponential Consequences
In 1988, a graduate student released what may have been the first internet worm. Robert Morris said it was meant to be harmless, a quiet experiment to measure the size of the internet. And then it met its own bug. The worm was supposed to re-infect machines only occasionally, so it couldn’t be swept away too easily. “Occasionally” was the intention. “Often enough to grind machines to a halt” was the implementation. The gap between those two words took down roughly 10% of every computer on the internet inside a day.
The lesson: test your edge cases, and respect exponential growth. A multiplier that looks harmless on paper can compound into catastrophe far faster than your gut expects, the way a lily that doubles each day takes the whole pond in a week and most of it on the final morning. Intuition is bad at exponentials. It always has been.
These stories aren’t here to frighten you. They’re here to show that the small skills you’re building (reading code carefully, testing systematically, paying attention to the edge cases everyone else waves past) aren’t really about passing exercises. None of these disasters began as a disaster. Each one began as a small thing someone judged too minor to check. That’s the quiet truth running under all three: catastrophe rarely arrives announced as catastrophe. It arrives as a detail. These habits are about building the kind of systems that patients lie down inside, and that spacecraft trust on the way to Mars.