Thursday, 2 March 2017


When Bad Code Caused Disaster: 10 Worst Programming Mistakes in History
By Moe Long,
Make Use Of, 27 February 2017.

Code is almost everywhere. The advent of modern computers arrived in the 1940s. In its rich history, programming enabled better communication, and led to advancements across a myriad of industries. Everything from space travel to telecommunications and healthcare has been revolutionized and affected by code.

Plus, programming can teach valuable life lessons. However, in its storied past, coding wrought destruction as well. Instances of a little bit of bad code caused disaster on a major level. The following are 10 of the worst programming mistakes in history.

1. Y2K Bug

Image credit: XDanielx/Wikimedia Commons

The Year 2000 bug, aka Y2K Bug or Millennium Bug, was a coding problem predicted to cause computer pandemonium. In the 90s, most computer programs listed four digit years in an abbreviated version. So 1990 read 90, 1991 written as 91, etc. By shortening four digit years to two digits, coders thus saved valuable memory. But computers were unable to recognize 2000 as simply 00. Further exacerbating the problem, 2000 was a leap year. Certain software applications didn’t account for the extra day.

Many feared that Y2K could bring down computers and electronics across the world. I remember my first DVD player bearing a shiny “Y2K Compliant” sticker. While the year 2000 rang in rather uneventfully from a software side, updating computers and apps throughout every industry cost roughly US$300 billion. Computers did not crash. Life proceeded as normal. But not without loads of money and work, which according to Slate reports may have been a waste.

Why it’s one of the worst programming mistakes: The Y2K panic was extremely costly, to the tune of US$300 billion. Plus, resources were redirected to fix this potential problem.

2. Heartbleed Bug


Appearing in the OpenSSL library, the Heartbleed Bug is a dangerous security vulnerability. The Transport Layer Security (TLS) protocol employs the OpenSSL cryptography library. Because of its widespread use in TLS, Heartbleed spread quickly. This bug allows virtually anyone on the internet to read memory on machines running affected iterations of OpenSSL. Up to 64 kb of system memory could be read. While the Heartbleed Bug was revealed to the public in 2014, it rolled out in 2012.

Improper input validation on account of a missing bounds check within the TLS heartbeat extension caused the bug. Since it was a bug in the heartbeat extension, the name Heartbleed thus spawned. A 2014 article in The Register reported that 1.5% of the most popular TLS-enabled sites remained vulnerable to the Heartbleed bug. However TLS implementations aside from OpenSSL were untouched. Therefore the Windows version of TLS and Mozilla’s Network Security Services were unaffected by the Heartbleed Bug. A patch eventually fixed the problem with OpenSSL version 1.0.1g. By adding bounds checks to prevent buffer over-read, the Heartbleed Bug was successfully patched.

Why it’s one of the worst programming mistakes: The Heartbleed Bug created a major security threat. The time between launch and patching left affected systems vulnerable for years. Any time there’s an computer vulnerability problem, this creates a huge data security concern.

3. World of Warcraft Virus Taken Too Literally

Image credit: WoW Wiki

World of Warcraft once suffered a computer virus of a different sort. In 2005, a digital plague infiltrated a few game servers. Thousands of characters fell prey to the Blood Virus. WoW developer Blizzard introduced Hakkar, the god of Blood. The considerable foe infected characters with corrupted blood. While the blood infection originally intended to afflict players within proximity to Hakkar’s body, player-to-player transfer occurred outside the realm. This unintentional means of spreading the blood virus spawned from in-game pets. Moreover, non-player characters (NPCs) became carriers.

Archimonde became the first infected server. Low level characters instantly died. Even powerful characters didn’t last much longer. Although a coding glitch perpetuated the virus via NPCs and pets, the virus wasn’t planned for release outside of Hakkar’s kingdom. While thousands of players died, World of Warcraft does not feature perma-death. Blizzard fixed the blood virus with rolling server restarts. But not before player corpses littered the WoW landscape.

Why it’s one of the worst programming mistakes: Ok, so World of Warcraft might not present a data security issue or life-threatening scenario - but gamers take their entertainment seriously. Blizzard spent hours resetting servers. Interestingly, in-game player behavior mimicked what might happen in a real-world epidemic with rampant outbreak, panic, and a collapse of civilization. Haven’t played WoW? Get started with this complete newbie’s guide.

4. Therac-25

Therac 25 interface simulation. Image credit: Wikibooks.

Whereas many programming mistakes cause vulnerabilities or dead in-game players, bad code actually can kill. The Therac-25 disaster occurred with the Therac-25 radiation therapy machine. Produced by Atomic Energy of Canada, the Therac-25 caused accidental radiation overdoses killing at least six patients. Investigations discovered that poor software and insufficient system development caused radiation overdoses. Largely these resulted from difficulty performing automated software tests.

The Therac-25 radiation overdoses serve as a reminder to create code that’s easily tested. Machines killing humans may sound like science fiction, but the Therac-25 incident proves otherwise. But this was really a result of human error in coding that caused these issues. Experts including Nancy Leveson found that inexperienced coders created buggy software. Moreover, just one programmer created the software and it was based on code from the Therac-6 and Therac-20.

Why it’s one of the worst programming mistakes: Whenever there’s loss of human life, a programming error is absolutely one of the worst examples of bad code.

5. Flight of the Ancient Mariner 1

Image credit: NASA/JPL

NASA uses quite a bit of tech. Its New Horizons Probe employs a PlayStation CPU. VP of Solutions Architecture and Engineering at NVIDIA Marc Hamilton blogs regularly about NASA’s use of NVIDIA hardware. The Mariner 1 rocket launched with a space probe slated to explore Venus. However slightly after launch, the rocket deviated from its intended flight path. Mariner 1 [pictured above] was destroyed shortly after takeoff.

A programmer’s minor mistake caused the Mariner 1 bug. Although reports differ, signs point to a missing hyphen. According to NASA archive documents, “the Mariner 1 Post Flight Review Board determined that the omission of a hyphen in coded computer instructions in the data-editing program allowed transmission of incorrect guidance signals to the spacecraft.” Renowned author Arthur C. Clarke (2001: A Space Odyssey) dubbed the Mariner 1 disaster “the most expensive hyphen in history.”

Why it’s one of the worst programming mistakes: The Mariner 1 blunder could have been easily avoided. Public service announcement: dear developers, please test your software.

6. AT&T Network Goes Down

Image credit: Unsplash via Pixabay

Can you hear me now? No. On January 15, 1990, over 50 percent of AT&T’s network crashed. In nine hours, 75 million calls went unanswered. While initial reports blamed hackers, the actual culprit was much worse: a standard software update. Remember this the next time you complain about Windows 10 updates. An error in just one line of code brought down AT&T’s network for several hours. A switch reset itself, but the bug meant that the second switch sent another message. Essentially a domino effect kicked off with the network continuing to repeat its error. Eventually AT&T devised a solution by reducing network load. The switches then reset themselves.

Despite heavy testing, a single statement crippled the network. The program was written in C. A break statement inside an if clause remained nested in a switch clause. The great AT&T outage of 1990 seems like a simple problem. Lots of missed calls, or as would be the case today a bunch of missed texts, Instagram, Twitter, and Snapchat notifications. Yet lack of communication carried huge monetary impacts. Companies like American Airlines suffered financial losses. American Airlines received two-thirds less calls because of the outage. The 1990 outage persists as an excellent example of why testing is important. Additionally, the AT&T outage serves as a reminder of the inherent connection between tech and the economy.

Why it’s one of the worst programming mistakes: Not only did AT&T’s network crumble, the several hours it remained down created a financial tumble.

7. Day of the Living Dead: St. Mary’s Mercy Hospital

Image credit: Vitalworks via Pixabay

In 2003 a software glitch incorrectly “killed” 8,500 people. St. Mary’s Mercy Medical Center in Grand Rapids, Michigan erroneously reported that many patients dead with a glitch in their patient management software system. This bad code disaster is rather harmless when compared to the Therac-25 fatalities, since no one actually died. Still, reading about your own demise is disconcerting - particularly when you’re alive and well.

False death reports weren’t limited to patients. This correspondence went out to insurance companies and Social Security offices. Because Social Security and insurance providers ensure eligible patients have Medicare, this presented quite a problem. St. Mary’s Mercy employees informed patients, government agencies, and insurance providers of the error. Ultimately the programming mistake didn’t gain much attention. It’s unclear if the coding error was ever corrected. However no further false death reports emerged. St. Mary’s Mercy hospital simply switched patient management software.

Why it’s one of the worst programming mistakes: Thankfully nobody actually died. But the damage control of ensuring continued healthcare coverage was a mess.

8. Prisoner Pre-Alpha: Early Release

Image credit: Alexas_Fotos via Pixabay

Michigan suffered a data processing glitch between 2003 and 2005. During that time a computer programming flaw caused early release for 23 prisoners by bumping down sentences for Michigan state prisoners. Lucky inmates benefited from sentences reduced anywhere from 39 to 161 days. While any accidental prison sentence termination is problematic, thankfully these were smaller infractions, like drug and embezzlement charges.

Software often aims to automate processes. By cutting down on manual tasks, our lives are theoretically easier. However this case with Michigan prisoners getting get out of jail early cards once again proves the value of software testing. A minor programming mistake carries massive ramifications especially in this example. Just imagine if prisoners released dabbled in more serious crimes.

Why it’s one of the worst programming mistakes: This incident could have been much worse, but early prisoner release is frightening.

9. Hartford Coliseum Falls

Image credit: Dave Gilbert/Flickr, CC BY-ND 2.0.

Although the 1978 Hartford Coliseum collapse cost a reported US$90 million loss, it could have been substantially worse. The Hartford Coliseum collapsed several hours after fans vacated the venue. Its steel-latticed roof failed to support the weight of wet snow. A building collapsed because of a simple programming error. The coder of the CAD software used to design the Hartford Coliseum failed to account for multiple variables. Instead the software programmer assumed steel roof supports would only face pure compression.

Engineers face many challenges. Using software should make their work easier. However failing to account for several variables leads to immense challenges. While you can simply patch an error in Minecraft, CAD software directly influences real world structures.

Why it’s one of the worst programming mistakes: Well, at least nobody died. But the economical devastation of an estimated US$90 million loss is huge.

10. I Got 99 Problems and a Pentium Is One

Image credit: Konstantin Lanzet/Wikimedia Commons

Generally Intel processors boasts better performance than AMD counterparts. However, AMD offers an excellent price-to-performance ratio. But in 1994, Intel’s Pentium microprocessors suffered a major problem. The 486DX and Pentium CPUs featured a floating-point unit (FPU). This FPU was a math coprocessor. Previous generation Intel CPUs processed math with integers. By including an FPU built in, this next generation Pentium chip promised significantly faster numerical calculations.

The Pentium FPU utilized a radix 4 STR algorithm. Incorrectly input information caused slightly incorrect calculations. But even a minor variation can mean massive problems as exhibited in the case of the Hartford collapse or Therac-25. About five entries in one thousand were left out throwing off the Pentium’s long division capabilities. Intel officially asserted that a scripting error caused lookup entry problems. Either way, Pentium’s math are attributed to bad code.

Why it’s one of the worst programming mistakes: A few significant figures off might not seem like much but in cases of engineering or healthcare precision it’s essential.

Bad to the Code: Programming Mistakes Happen

Programming mistakes have occurred since the inception of coding. As the use of code in a variety of fields continues to expand, this trend likely won’t disappear anytime soon.

There are plenty examples of programming mistakes. Some are fairly innocuous like a World of Warcraft bug. Others result in death either real (Therac-25) or imagined (St. Mary’s). Don’t let these famous examples deter you from coding. Check out this guide to choosing the right web programming language.

Top image credit: PublicDomainPictures/Pixabay.

[Source: Make Use Of. Edited. Some images added.]

No comments:

Post a Comment

Please adhere to proper blog etiquette when posting your comments. This blog owner will exercise his absolution discretion in allowing or rejecting any comments that are deemed seditious, defamatory, libelous, racist, vulgar, insulting, and other remarks that exhibit similar characteristics. If you insist on using anonymous comments, please write your name or other IDs at the end of your message.