Famous bugs and their consequences
In programming, a bug is an error in a program or system that causes it to behave in an unexpected way. Sometimes the result is nothing more than an annoying glitch on a screen. Sometimes it means lost money, a failed rocket launch, a disabled ship, or even human casualties. The history of technology proves one thing very clearly: in complex systems, even the smallest mistake can become the beginning of a major disaster.
The word bug entered technical language long before modern computers. One of its early uses is usually associated with Thomas Edison. In the late nineteenth century, he used the word to describe small technical defects that prevented an invention from working as intended. In an 1878 letter, Edison wrote that after the first flash of intuition, difficulties almost always follow: the device refuses to work, “bugs” appear — small faults and obstacles — and months of observation, research, and effort may be required before the invention reaches commercial success or is finally judged a failure.
The word debugging, which today means testing and correcting software, was also used before programming became part of everyday life. In the mid-twentieth century, it could be found in connection not with software, but with technical systems, including aircraft engines.
The computer-age fame of the word bug is closely connected with Grace Hopper and the Harvard Mark II computer. In 1947, engineers discovered that a malfunction had been caused by a real moth trapped inside an electromechanical relay. The insect was carefully removed and taped into the logbook. The note beside it read: “First actual case of bug being found.” It is important to understand that this was not the first use of the word bug in a technical sense. But the episode was so vivid and so literal that it became part of programming folklore forever.
In our own century, real insects are unlikely to break a program. Their digital relatives, however, create enormous problems every year. History is full of cases in which a single line of code, one wrong variable, or one missing symbol led to consequences wildly out of proportion to the size of the mistake.
Broken in 60 seconds
In 2016, owners of Apple devices accidentally discovered that setting certain iPhones or iPads to January 1, 1970, and then restarting them could turn the device into a “brick.” The Apple logo would remain frozen on the screen, and the device would no longer boot normally. Online jokes quickly appeared about a secret Easter egg, a retro Apple logo, or a way to download paid apps for free. The result was always the same: instead of a smartphone, the user ended up with a serious problem.
The bug affected 64-bit Apple devices using A7 processors and newer. The reason was connected with Unix time. In Unix-like systems, January 1, 1970, is the starting point, and time is stored as the number of seconds that have passed since that moment. For humans, this may seem unnatural. For computers, it is convenient and logical. Problems begin when the software fails to handle boundary values properly. If the system unexpectedly receives a zero or near-zero time value and then performs additional calculations with it, the result can be destructive.
Apple later prepared fixes, but the episode remains a useful reminder: even the date in a settings menu may not be a harmless decorative number, but part of the deep logic of the system.
Similar errors are familiar to developers of older games and programs. In the MS-DOS era, bugs caused by counter overflow were common. One famous legend about Civilization claims that the peaceful Gandhi could become wildly aggressive because his aggression value dropped below zero and wrapped around to the maximum. The historical accuracy of that particular game story is disputed, but the type of error is absolutely real: if a variable allows only values from 0 to 255, subtracting one from zero may produce an unexpected result. In other games and programs, similar errors could turn maximum statistics into zero, break balance, or disrupt the system entirely.
There is also a more serious date that programmers still remember: January 19, 2038. At that moment, systems using a 32-bit signed integer to store Unix time will exceed the maximum representable value. Many modern systems have already been adapted to this problem, but old embedded equipment, industrial controllers, and forgotten legacy systems may still be vulnerable.
The most expensive line in history
Mariner 1 was a NASA spacecraft created to study Venus. It was launched on July 22, 1962, but only a few minutes after liftoff, the rocket was destroyed by command from the ground.
The problems began soon after launch. The rocket started drifting away from a safe trajectory, and specialists decided to destroy it in order to avoid even more dangerous consequences. For a long time, popular culture described this as the story of the “most expensive hyphen” in history. That version, however, is not quite accurate.
The error was not an ordinary hyphen, but a missing overbar in a mathematical notation used when formulas were translated into program logic. Without that mark, the guidance system interpreted the data incorrectly and responded to deviations in the wrong way. As a result, the rocket received improper course-correction commands. One tiny line in a formula was important enough to doom the mission.
The copy-and-paste method
Ariane 5 was a European launch vehicle designed to carry payloads into orbit. Its first launch took place on June 4, 1996, and ended in one of the most famous software failures in history.
A few dozen seconds after liftoff, the rocket veered from its intended trajectory and was destroyed. Scientific satellites worth hundreds of millions of dollars were lost with it.
The bug lay in software inherited from Ariane 4. For the previous rocket, that logic had been acceptable, but Ariane 5 had different flight dynamics and a different trajectory profile. At one point, a value related to the rocket’s motion became too large to be converted from a 64-bit floating-point format into a 16-bit signed integer. An exception occurred, the inertial reference system failed, the backup system repeated the same failure, and the rocket lost control.
This became a classic example of the danger of reusing code without reexamining its assumptions. Copy-and-paste is not evil in itself. But code written for one system can become deadly in another if no one verifies what assumptions are hidden inside it.
Idiot-proofing
In September 1997, the missile cruiser USS Yorktown was left “dead in the water” for several hours after a failure in its computerized control system. Fortunately, this happened during manoeuvres, not in combat.
The ship was part of the Smart Ship program and used a network of Windows NT computers connected by high-speed communication lines. The automation was intended to reduce crew size and lower operating costs. Everything worked until an invalid value entered the system.
The bug was both simple and revealing: a zero was entered into one field, after which the program attempted to divide by zero. Every schoolchild knows that division by zero is impossible, but a computer does not “know” anything on its own. It follows instructions. If the programmer has not provided input validation and exception handling, the system may do more than display an error — it may drag other components down with it. That is what happened: the failure spread through the network and disabled important control elements.
The incident is often cited as an example of why critical systems must be designed not only for normal operation, but also for operator mistakes, bad data, and unexpected scenarios.
One third of a second
Not all software errors end without casualties. One of the most tragic examples occurred in 1991 during the Gulf War. An American Patriot missile system failed to intercept an Iraqi Scud missile that struck a barracks in Dhahran, Saudi Arabia. Twenty-eight American soldiers were killed.
The bug was connected with the accumulation of error in time calculations. The Patriot system stored time in tenths of a second, but because of the way fractional numbers are represented in binary form, a small inaccuracy was introduced. When the system had been running only briefly, the error was insignificant. After long continuous operation, however, it accumulated to roughly one third of a second.
For an ordinary person, a third of a second is almost nothing. For a missile-defense system, it is enormous. In that time, a missile can travel hundreds of metres. The computer detected the target, but because of the timing error, it miscalculated the missile’s position and concluded that the target was no longer where it needed to be intercepted. The interception attempt was cancelled.
This story is especially frightening because the error was mathematically small but practically fatal. In a world of high speeds, weapons, and automated decisions, even fractions of a second have a price.
When machines begin selling to each other
Black Monday — October 19, 1987 — became the day of one of the sharpest stock-market collapses in American history. The Dow Jones Industrial Average fell by more than 20% in a single day. The crash affected markets around the world and became a lasting symbol of how quickly a financial system can slide into panic.
Calling this a simple “bug” would be inaccurate. The crash had several causes: overvalued markets, rising interest rates, macroeconomic fears, tensions in the global financial system, and the weaknesses of market infrastructure at the time. But program trading and portfolio insurance strategies did play an important role in amplifying the fall.
The problem was that many large market participants used automated strategies intended to protect portfolios from losses. When the market began to decline, these systems started selling futures and stocks in order to reduce risk. But because similar algorithms were triggered by many players at once, selling intensified the decline, the decline triggered more selling, and the market entered a chain reaction.
Financially, Black Monday did not become the end of the world economy. Psychologically, however, it was the moment when it became clear that computer systems in the market were no longer merely assisting people. Under certain conditions, they could accelerate human fears, magnify crowd behaviour, and create dynamics that people themselves could no longer stop in time.
That is why the story of bugs is not only a story about programmers. It is a story about our dependence on invisible systems. Today, code runs banks, aircraft, cars, hospitals, exchanges, phones, power grids, and military equipment. The mistake may be tiny. The consequences may be enormous.