One of the most expensive software failures in history happened because a number became too large for the system that stored it.
In 1996, the Ariane 5 rocket exploded less than a minute after launch. The cause was not a simple mechanical failure. A software error in the guidance system played a central role. A value was converted from a larger number format into a smaller one, and the result could not fit.
This kind of problem is called an overflow. The story became a famous lesson in software engineering: code that worked in one system may fail dangerously when reused in a different environment.
What happened in simple words
The rocket’s software tried to convert a large number into a smaller format. But the number was too large for that smaller format. The system could not handle the conversion properly.
That error affected the guidance system, and the rocket received wrong information about its movement. The system reacted incorrectly, the rocket became unstable, and it was destroyed shortly after launch.
The important lesson is not only that a number overflowed. The deeper lesson is that software must be tested in the real conditions where it will run.
Why reused code became risky
Part of the software came from the earlier Ariane 4 system. That code had worked before, but Ariane 5 had different flight behavior. It moved differently and created values that the old assumptions did not safely handle.
This is a common risk in programming. Reusing code can save time, but reused code carries old assumptions. If the new system behaves differently, those assumptions can become dangerous.
Where this happens in normal software
You do not need to build rockets to face this problem. Similar issues can happen in everyday software:
- a database field is too small for a new value
- a payment amount is rounded incorrectly
- a counter grows beyond its expected limit
- a file size is larger than the system expects
- old code is reused for a new product without enough testing
- a mobile app assumes a screen size or device behavior that is no longer true
The bug may look small, but the result can be serious when the system depends on that value.
The danger of silent assumptions
Software often contains assumptions that are not written clearly. A developer may assume a number will always stay small, a user count will never exceed a limit, or a value will always arrive in a certain format.
Those assumptions may be true today, but false tomorrow. Systems grow, users change, data changes, and old limits become unsafe.
Good systems check limits
A safer system does not simply trust every value. It checks ranges, handles errors, and decides what should happen when something unexpected appears.
For example, if a value is too large, the system should not fail unpredictably. It should reject the value, log the problem, use a safe fallback, or stop the process in a controlled way.
Testing must match reality
Testing only the old scenario is not enough. When code is reused in a new environment, the tests should reflect the new environment.
Teams should ask:
- What values can this system now receive?
- Are the old limits still valid?
- What happens at the maximum value?
- What happens when conversion fails?
- Does the system fail safely?
These questions are valuable not only for aerospace, but also for finance, healthcare, logistics, education, and business software.
Useful habits for developers
- Avoid unsafe type conversions when possible.
- Document the expected range of important values.
- Test boundary cases, not only normal cases.
- Review reused code for old assumptions.
- Handle errors explicitly.
- Make failure safe, not chaotic.
The hidden lesson: “worked before” is not enough
One of the most dangerous phrases in software is “it worked before.” That may be true, but it worked under certain conditions. When the conditions change, the same code can behave differently.
Reliable software is not only code that worked yesterday. It is code that is understood, tested, and safe under today’s conditions.
Bottom line
The Ariane 5 failure teaches that software assumptions, type limits, and reused code must be treated seriously. A small conversion error can become a large system failure when nobody checks whether old code still fits the new reality.