The $460 million typo

In 1996, a tiny piece of code nearly destroyed a rocket.

Ariane 5 was being launched for the first time.

About 37 seconds after launch, the rocket suddenly veered off course.

The onboard computers detected something impossible.

Both guidance computers failed.

The rocket was destroyed.

The cause?

A number that was too large for a 16-bit integer.

The Ariane 5 software inherited code from Ariane 4.

But Ariane 5 was flying differently.

One conversion that had been safe on the old rocket overflowed on the new one.

A tiny assumption survived years of testing because nobody asked:

“Is this assumption still true in the new system?”

The lesson isn't “integers are dangerous.”

It's much bigger:

Old code carries old assumptions.

And when the environment changes, those assumptions can become vulnerabilities, failures, or disasters.

Good software engineering isn't just asking:

“Does this code work?”

It's asking:

“Under what assumptions does this code work?”

That's one of the reasons automated security analysis matters.

Not because tools replace engineers.

Because sometimes the most dangerous bugs are hiding inside assumptions nobody remembers making.

That's also the kind of problem we're interested in at Debuggix.