Engineering decisions that changed — and ended — lives

Aviation Failures

The Ariane 5 Explosion: How 10 Lines of Reused Code Destroyed $500 Million in 37 Seconds

May 11, 2026·15 min read
The Ariane 5 Explosion: How 10 Lines of Reused Code Destroyed $500 Million in 37 Seconds

© ESA

Picture the scene at the Guiana Space Centre in Kourou on the morning of June 4, 1996.

In the control room, scientists and engineers who had given ten years of their careers to this moment are watching the screens. Twenty countries contributed to this rocket. Seven billion dollars were spent building it. Outside, on the launchpad, stands a vehicle that represents Europe's most ambitious technological undertaking since the Concorde.

The countdown reaches zero. The engines ignite. For thirty-seven seconds, Ariane 5 rises exactly as planned.

Then it veers off course. The automated self-destruct system activates. A fireball tears the rocket apart over the jungle of French Guiana.

In the control room, there is silence.

A decade of work, gone in just over half a minute. Four scientific satellites that can never be replaced, falling as wreckage into the jungle. And the cause — though no one in that room knows it yet — is a piece of code that was copied from a different rocket without anyone checking whether it would work on this one.

Europe's Answer to America and the Soviet Union

To understand why this disaster was so devastating, you have to understand what Ariane 5 meant politically — not just technically.

The European Space Agency was founded in 1975 by ten European nations with a single clear purpose: to end Europe's dependence on American and Soviet rockets to reach space. If you needed to launch a satellite in the 1960s or early 1970s, you had to ask the superpowers for permission and pay their prices. For European governments and companies, this was not just expensive — it was a strategic vulnerability.

ESA's answer was the Ariane programme. Ariane 1 launched from Kourou in 1979. Then came Ariane 2, Ariane 3, and then the vehicle that made Europe genuinely competitive in the commercial launch market: Ariane 4.

By the time Ariane 5 was being prepared for its maiden flight, Ariane 4 had completed 116 launches, with 113 successes. It had captured 50% of the global commercial satellite launch market — ahead of NASA, ahead of the Soviet Proton, ahead of every competitor. It was not just a functioning rocket. It was a geopolitical statement. Europe could compete.

Ariane 5 was built to be better. More powerful, capable of launching heavier payloads into geostationary orbit, designed for the next generation of commercial satellites. But to understand why it was actually built — and why the decisions that destroyed it were made — you have to go back to 1985 and a spacecraft that no longer exists.

The Capsule That Never Flew

In 1985, ESA began development of Hermes — Europe's first crewed spacecraft. A reusable space plane, roughly analogous to the American Space Shuttle, designed to carry astronauts to and from orbit. Ariane 5 was built specifically to launch Hermes. The two programmes were conceived as a pair — the rocket and the spacecraft that would sit on top of it.

Then, on January 28, 1986, the Space Shuttle Challenger broke apart seventy-three seconds after launch, killing all seven crew members.

The Challenger disaster changed everything. Not just for NASA — for every space programme on the planet. ESA became acutely aware of the risks of crewed spaceflight, and began redesigning Hermes from the ground up to meet new safety standards. Then they redesigned it again. And again. And again.

Four complete redesigns over six years. Each one more expensive than the last. Each one pushing the programme further over budget and behind schedule.

In January 1992, after years of escalating costs and with no end in sight, ESA cancelled Hermes entirely.

The consequences for Ariane 5 were immediate and severe. The rocket that had been designed with a specific purpose — to carry Hermes into orbit — suddenly had no payload to carry and no clear reason to exist. The programme had been ongoing for years. Billions had already been spent. Cancelling Ariane 5 too would mean writing off an enormous investment.

ESA made the only politically viable decision: they would continue. Ariane 5 would be repositioned as the commercial successor to Ariane 4. It would compete for satellite launch contracts. It would carry Europe's hopes for maintaining its share of the global launch market.

This decision, made under pressure and without a clean technical rationale, set the chain of events that would end in a fireball over the jungle.

The Decision That Destroyed the Rocket

With Ariane 5 now repositioned as a commercial vehicle, schedule pressure became immense. Every month of delay was a month of lost revenue, a month of market share handed to competitors. Budget pressure was equally intense — the programme had already run long after the Hermes cancellation threw its financing into uncertainty.

In this environment, technical leaders made a decision that seemed entirely rational at the time: to save time and reduce risk, they would copy the navigation software from Ariane 4 directly into Ariane 5.

Why rewrite code that had worked perfectly for years? Why introduce new bugs when you have proven software? The logic was seductive. The project was behind. The code worked. Use it.

Engineers raised concerns. They pointed out the obvious problem: Ariane 5 flew approximately five times faster than Ariane 4 during the critical early phase of launch. The software had been written and validated for a rocket with a specific flight profile. Ariane 5's flight profile was fundamentally different.

They were ignored.

This is not an unusual story. It is, in fact, one of the most common stories in engineering disaster post-mortems. The people who understood the technical risk raised the alarm. The people who controlled the budget and the schedule made the decision. The engineers' concerns were noted, overridden, and forgotten.

Ariane 4's software went into Ariane 5 unchanged.

The Bug That Nobody Looked For

To understand exactly what went wrong, you need to understand one concept: integer overflow.

Imagine you have a glass jar that can hold exactly 32,767 marbles. You start filling it. While it's below capacity, everything is fine. But the moment you try to push in that 32,768th marble, the jar doesn't simply stop accepting marbles — it shatters. In computing, the equivalent happens when a number exceeds the maximum value a variable can hold.

In Ariane 5's guidance system, there was a variable that measured the rocket's horizontal velocity — a value known as BH, or "horizontal bias." This value was stored as a 64-bit floating point number: a very large container, capable of handling enormous values without any difficulty.

At a certain point in the flight sequence, this value needed to be converted to a 16-bit signed integer — a much smaller container, with a maximum value of 32,767.

On Ariane 4, this conversion had always worked without incident. The rocket was slower. The BH value during the relevant flight phase never exceeded 32,767. The jar was never overfilled.

On Ariane 5, the rocket was dramatically faster. The BH value during the same phase exceeded 32,767. The conversion failed. The jar shattered.

The guidance computer did not know how to handle the failure gracefully. It shut down — and it reported its own shutdown error as if it were valid flight data, transmitting the error code through the data bus to the flight control system. The backup guidance computer, running identical software, had already shut down for exactly the same reason 72 milliseconds earlier.

The flight control system received error codes from both computers. It interpreted them as trajectory data. It tried to correct a flight path that was, in reality, fine — the rocket was flying perfectly well. The corrections caused Ariane 5 to veer sharply off course. Aerodynamic stress began tearing the vehicle apart. The automated self-destruct system activated.

Thirty-seven seconds. $500 million. Gone.

The Most Damning Line in the Report

Here is the detail that should make any engineer's blood run cold.

When the investigation board examined the code that caused the failure, they found that the BH conversion function — the piece of software whose failure destroyed the rocket — served no operational purpose on Ariane 5.

The function had been needed on Ariane 4 for a specific reason related to that rocket's alignment procedure. Ariane 5 used a different alignment procedure. The function was not needed. It did nothing useful.

The investigation board's report states it plainly: the problematic code "has no useful function in the Ariane 5" and was retained only "for reasons of commonality."

A $500 million rocket was destroyed by dead code. Code that did nothing. Code that existed only because it had existed in the previous system and nobody had explicitly removed it. Code that was never exercised during ground testing because no one thought to check whether it could even produce a value that exceeded the 16-bit limit.

The exception was detected — the software did catch the overflow. An exception handler existed and was triggered. But the exception handler responded by shutting down the computer and reporting the error code as flight data, with no flag, no indication that the value was an error rather than a real trajectory reading.

The system designed to catch failures became the mechanism of failure.

And both redundant computers ran the same software. Redundancy only works if the redundant systems can fail independently. When they share the same bug, they share the same failure mode. The primary computer failed. The backup had already failed 72 milliseconds earlier. There was nothing left.

The Man Who Found the Truth in 36 Days

Within days of the explosion, ESA and CNES appointed an independent inquiry board. The chairman was Professor Jacques-Louis Lions — a member of the Académie des Sciences and one of France's most distinguished mathematicians, described by colleagues as cold and methodical, a man who did not tolerate assumptions.

When he accepted the assignment, Lions reportedly said: "I am not here to protect positions or reputations. I am here to find the truth."

He meant it. The board worked without the institutional protectiveness that so often softens post-disaster investigations. They did not look for ambiguity where there was none. They did not qualify their findings with diplomatic hedging.

The report was completed in 36 days.

It remains one of the clearest technical failure analyses ever written. Its conclusions are precise and unsparing: the failure was caused by a software specification error — specifically, the reuse of code without validating that its assumptions remained valid in the new context. The root cause was a failure of requirements engineering. An assumption invisible in the code — that BH values would never exceed 32,767 — had never been explicitly stated, never been challenged, and never been tested against Ariane 5's actual flight profile.

The board's position on software safety was stated with unusual directness: "The exception was detected but was handled inappropriately because the view had been taken that software should be considered correct until it is shown to be at fault."

Lions and his board favoured the opposite view — that software should be assumed to be faulty until rigorous testing demonstrates otherwise. This distinction between those two philosophies — innocent until proven guilty versus guilty until proven safe — is not abstract. In systems where failure kills people or destroys rockets, it is the difference between the culture that built Ariane 5 and the culture that might have saved it.

The Shadow of Challenger

There is a pattern in these disasters that is worth naming directly.

On January 27, 1986 — the night before Challenger launched — engineers at Morton Thiokol pleaded with NASA management not to launch. The O-ring seals on the solid rocket boosters had never been tested at the overnight temperatures forecast for the morning. The engineers knew the seals could fail. They said so, clearly and repeatedly.

NASA management overruled them. The schedule pressure was enormous. The launch had already been delayed. They launched.

Seventy-three seconds later, Challenger broke apart.

In the Ariane 5 programme, engineers warned that copying Ariane 4's software into a rocket flying five times faster was technically unsound. They raised the concern formally. They were overruled. The schedule and budget pressures were too great.

Thirty-seven seconds after launch, Ariane 5 exploded.

The specific failure modes are different. The rockets are different. The decades are different. But the underlying pattern is identical: a culture in which schedule and budget pressure systematically overrides the concerns of the engineers who understand the risk.

Challenger was 1986. Ariane 5 was 1996. Boeing 737 MAX was 2018. The lesson does not seem to stay learned. The pressure is always there. The engineers who raise concerns are always there. The decision to override them is always, in the moment, framed as reasonable.

The Cargo That Was Lost

The four satellites destroyed in the explosion were part of the Cluster mission — a scientific project designed to study Earth's magnetosphere and its interaction with the solar wind.

The Cluster satellites had taken years to build. They represented the work of scientists across fourteen countries. They were not interchangeable instruments — each was precisely calibrated to work in formation with the others, measuring phenomena that required simultaneous observations from multiple points in space.

They were irreplaceable.

A replacement mission — Cluster II — was eventually launched in 2000. It cost an additional $150 million and four more years of work. The questions about Earth's magnetic environment that Cluster was supposed to answer in 1996 went unanswered until 2000 at the earliest.

All of it — the delay, the cost, the lost years of scientific data — because of an integer overflow in code that served no purpose on the rocket that carried it.

What This Means for Anyone Who Writes Code

I have spent years writing software for systems where errors have real financial consequences — failed payments, corrupted transactions, lost data. The Ariane 5 failure is not a story about exotic aerospace engineering. It is a story about assumptions.

Reused code carries the assumptions of the context it was written for. When you change the context, you must challenge every assumption. "It worked before" tells you only that it worked in the conditions it was previously tested in. It tells you nothing about whether it will work in conditions it has never encountered.

Dead code is not neutral. Code that serves no purpose is not safe code — it is untested code attached to a live system. If you don't know what it does, you don't know what it can break. Removing it is not a luxury — it is maintenance.

Exception handlers must fail safely. Catching an error is not enough. What you do with it determines whether your safety mechanism becomes your failure mechanism. An exception handler that outputs its error code as flight data is, in the most precise sense, worse than no exception handler at all.

Redundancy requires independent failure modes. Two computers running identical software are not a redundant system. They are one computer with extra hardware. True redundancy requires that a fault in one system cannot, by definition, produce the same fault in another.

The cost of testing is always less than the cost of not testing. The investigation cost money. Cluster II cost $150 million. The reputational damage to European space ambitions cost more. The cost of testing the BH conversion function against Ariane 5's actual flight envelope — of running the software against the real numbers the new rocket would generate — would have been negligible in comparison.

When engineers raise concerns about technical risk, the response matters. Not because engineers are always right. But because a culture that systematically silences risk concerns loses its ability to catch the ones that are right. Challenger. Ariane 5. Therac-25. Boeing 737 MAX. The pattern is not a coincidence.

Go Deeper

If this story changed how you think about software, these resources are worth your time:

To understand what went wrong:

To build software that doesn't fail this way:

To understand why organisations make these decisions:

Next: The Therac-25 — when a race condition in medical radiation software gave patients lethal doses.

Sources:

← Back to all articles