Pinterest Stumbleupon Whatsapp
Advertisement

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 6 Life Habits That Programming Could Teach You Today 6 Life Habits That Programming Could Teach You Today Everything important that you need to know about living a successful life, you can get from a computer program. Don't believe me? Read on. Read More . 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

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 $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 $300 billion. Plus, resources were redirected to fix this potential problem.

2. Heartbleed Bug

heartbleed-bug
Image Credit: OpenClipart-Vectors via Pixabay

Appearing in the OpenSSL library, the Heartbleed Bug is a dangerous security vulnerability Heartbleed – What Can You Do To Stay Safe? Heartbleed – What Can You Do To Stay Safe? Read More . 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.

Advertisement

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

WoW-Corrupted-Blood
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 Getting Started With World Of Warcraft: A Complete Newbie’s Guide Getting Started With World Of Warcraft: A Complete Newbie’s Guide Here’s what you need to know if you’ve never tried World of Warcraft before. Read More .

4. Therac-25

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

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 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

at&t-network-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 Windows Updates Are Set to Get Less Annoying Windows Updates Are Set to Get Less Annoying Under the new system, Windows 10 updates should be smaller in size, be downloaded more efficiently, and put less strain on your system resources. A change you probably won't even notice. Read More . 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

st-mercys-faux-dead
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

prison-accidental-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

Although the 1978 Hartford Coliseum collapse cost a reported $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 $90 million loss is huge.

10. I Got 99 Problems and a Pentium Is One

Generally Intel processors boasts better performance than AMD counterparts. However, AMD offers an excellent price-to-performance ratio AMD's New Plan: Make Virtual Reality Cheaper for You AMD's New Plan: Make Virtual Reality Cheaper for You AMD seems to be switching gears in 2016, and if all goes well, they're going to be a big player in the virtual reality market. Read More . 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 How to Choose the Right Web Programming Language to Use How to Choose the Right Web Programming Language to Use Why should certain languages be chosen over others in any given scenario? This article will provide a checklist of questions the programmer should ask in order to choose which language to use. Read More .

What historical examples of bad code do you remember? Leave a comment below with your picks of programming blunders!

Image Credit: nouskrabs and McIek via Shutterstock.com

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Nicolas
    March 12, 2017 at 11:56 am

    An event like the one from AT&T also happened here in Belgium last week. Base, one of our carriers, rolled out an update to their servers. As a consequence, half the network was down. It took them half a day to recover from that. Things like that still happen today, unfortunately.

    • Moe Long
      April 3, 2017 at 2:00 pm

      Oh my! Thanks for sharing. Totally didn't even hear about that one. Which network was this? I'd be keen to look up a bit more info.

  2. Mike
    March 8, 2017 at 9:33 pm

    First, it irks me that people make these sweeping statements that the Y2K bug was all smoke and mirrors. First it was based on the current address limitations back when mainframes roamed the earth and only eight bits were available. Yes, someone could hypothesize that this limit would be changed, but you have to work with what you have at the time.

    Second, I was tasked with cleaning up the problem and few of the naysayers were competent to even judge (being journalists not programmers). The problem was HUGE and it would have created massive dislocations on many levels of society.

    While the coding wouldn't have crashed society, the failures of banks for a month or two or hospitals or communications would have. IF we had waited for the problem to manifest and started at day zero it would have taken months to correct and what would have happened while everyone sat on their hands waiting? Go back to barter and smoke signals, or the telegraph? I was hired to work in the banking and stock industries and the problems I found would have brought those industries to a halt. Because there were no "guts and blood in the streets" everyone feels that it was some scam. What really happened is we just missed the bullet.

    Finally, there have been studies on the amount of bugs in software calculated on Klocks or per thousand lines of code. The truth is that there are thousands if not millions of bugs in all the software even today that are ignored because they would take too or too much money to resolve and don't impact most people one wit.

    I love using Microsoft operating systems and counting the bugs, as I use the OS it is like an Easter Egg hunt for me. There was a particular bug in the MS calculator app that lasted for years and I would go check every so often to see if it had been fixed. I haven't checked lately, it may still be there and it has lasted from 95 on into XP if my memory serves me. That would be a good what, ten years?

    Every time someone finds a bug, particularly a nasty one, the masses get a knot in their nickers, wring their hands, and running in circles crying, "The sky is falling"; but truth is, few bugs or issues warrant any real angst. They have to print something on a slow day and the media will snatch up anything when that happens.

    IF we are lucky, most of the bad ones will be caught by the test quality teams and the masses can go about their daily routines undisturbed by the nitty-gritty of the details that underpin their lives.

  3. sdgengineer
    March 7, 2017 at 5:34 pm

    My son pointed this out:

    No mention of Mars Climate Orbiter: Disintegrated in the atmosphere of Mars due to Lockheed Martin and NASA using different measures of thrust (pound-seconds vs newton-seconds)

    • Moe Long
      April 3, 2017 at 2:06 pm

      An excellent example! Nice reminder of the importance of match (this coming from a writer...).

  4. Johnny R
    March 7, 2017 at 3:08 pm

    Last time I checked, computers all around the world speak English. So remember that when you buy something from a company that out-sources IT coding to India, or is a proponent of H1B Visa workers from India. Last time I checked, most people from India CANNOT speak English correctly and use horrible grammar. Liberals might be forgiving of that, but computers are not. Not to mention it's HARD to work with an IT guy who doesn't speak English very well.... so mistakes are often missed during discussions.

  5. Godel
    March 7, 2017 at 4:52 am

    Re: No 5 You say" Public service announcement: dear developers, please test your software."

    Yes, but then have someone ELSE check your software as well.

    • Eddie G
      March 8, 2017 at 7:55 am

      And then?.....have someone ELSE check it and someone ELSE check it...and then?....test it in a test environment....over and over until you can break it....then....fix it and run it again...for longer time periods until you CAN'T break it....after that?...it's just about ready for production..

  6. Joe
    March 6, 2017 at 7:50 pm

    You left out the bash bug. It was in most of Linux systems (and UNIX?) for decades before being "publicly" discovered. It affected a huge number of systems leaving them vulnerable to attack and some are undoubtedly still vulnerable with firmware that hasn't or can't be updated. This article says it was bigger than heartbleed. https://www.cnet.com/news/bigger-than-heartbleed-bash-bug-could-leave-it-systems-shellshocked/

  7. Martin Green
    March 6, 2017 at 7:14 pm

    Re Slate and Y2K... a lot of uninformed people these days believe that the Y2K problem was a massive hoax and the mitigation effort a huge wast of money. Why do they think this? Because come 12:01am on Jan 1st, 2000, not much bad stuff happened. What they ignore is that not much happened PRECISELY because of the most aggressive and coordinated proactive infrastructure program in Worldwide tech history. I was a contract Enterprise software developer back then, and although I personally kept on churning out new systems, for over 5 years from the early 90's there were usually at least three times as many contractors working on Y2K than on new development in the Enterprises I worked for at that time.

    Claiming that all that work preventing the computer apocalypse was a waste of time is like LA spending billions making all their buildings quake proof, and then after The Big One hits, claiming it was all boondoggle because only a dozen people died.

    • silverlokk
      March 7, 2017 at 11:49 am

      Well said, analogy spot on.

      Also, 1) the two-digit representation for the year didn't start in the 90s, but well earlier. And, 2) both RAM and storage were expensive then, so halving the representation for the year was more of a design decision driven by economics.

      On the other hand — and it might've been mainly the mainstream media guilty of this — there was excessive panic over Y2K. Planes falling out of the sky, elevators plunging to the ground, some other stories I don't recall at the moment — I don't know of any serious IT professional who issued warnings about those.

      However, Y2K was real. I think it was in Texas where the locks in prisons defaulted to the Open position when the clock struck midnight of January 1, 2000. Centenarians received notices requiring them to report for Grade School. I was using an iMac until shortly after Jan 1, 2000, and Outlook wasn't sorting my mailbox properly. Last two examples are far from disastrous, first one would have been

  8. Jim Frederick
    March 6, 2017 at 6:47 pm

    What about the Toyota accelerator problem caused by somebody using recursion in FW that resulted in a stack overflow? Search for "toyota acceleration recursion".

  9. Jim Rogers
    March 6, 2017 at 4:51 pm

    Changes were made to many programs in the system I worked on just prior to the year 2000. I guarantee that it wasn't a wasted effort, as they would have failed otherwise.

  10. Joe
    March 6, 2017 at 2:56 pm

    I worked on the Therac 25 for Atomic Energy of Canada Ltd. back around 1985. Dec PDP's were used to control their linear accelerators. As I recall, the computers for the Therac 25 were limited to 16K of memory which forced the programmers to be very tight with their code. This may have contributed in some way to the error that occurred. The solution that was worked out to prevent the issue from occurring involved a bit of code and a hardware switch to verify the position of the beam flattening filter. It's a terrible tragedy what happened to those poor patients and it's also sad that this error, easily corrected, killed the Therac 25 program. It was an advanced machine with some great engineering features, but when faith was lost, the program died.

  11. old_guy
    March 5, 2017 at 11:20 pm

    In 1982, during the Falklands War, the Exocet Missle became noted worldwide when Argentine Navy Dassault-Breguet Super √Čtendard warplanes carrying the AM39 Air Launched version of the Exocet caused irreparable damage which sank the Royal Navy destroyer HMS Sheffield on 4 May 1982. The Sheffield had not updated their automated IFFO ( identify friend-or-foe) defense system to recognize the Exocet as a "foe".

    1998 - Windows NT. the USS Missle Frigate Yorktown deployed Win NT running the whole ship , went "blue screen" and hung. Yorktown was "dead in the water" ~ 30 miles offshore for over 2.5 hours ( including comms). had to be towed back to port. the "Smart Ship" program was later loudly declared a success and the ships used were rapidly decommissioned.

    but they did not learn for the past-
    2007- U.K. - The Type 45 destroyers now being launched will run Windows for Warships: and that's not all. The attack submarine Torbay has been retrofitted with Microsoft-based command systems, and as time goes by the rest of the British submarine fleet will get the same treatment, including the Vanguard class (V class). The V boats carry the UK's nuclear weapons and are armed with Trident ICBMs, tipped with multiple H-bomb warheads.

    Feb 2007 -
    "The new US stealth fighter, the F-22 Raptor, was deployed for the first time to Asia earlier this month. On Feb. 11, twelve Raptors flying from Hawaii to Japan were forced to turn back when a software glitch crashed all of the F-22s' on-board computers as they crossed the international date line. every fighter completely lost all navigation and communications when they crossed the international date line. They reportedly had to turn around and follow their tankers by visual contact back to Hawaii. According to the CNN story, if they had not been with their tankers, or the weather had been bad, this would have been serious."

  12. old_guy
    March 5, 2017 at 11:06 pm

    1982, Falklands War - HMS Sheffield is sunk by an Argentinian Exocet missile in the Falklands war - Since Exocet was also used by U.K. forces, Command on HMS Sheffield failed to update the shipboard computerized defenses to identify an Argentine Exocet as a "threat", allowing it in.

    1998 - A Windows NT system failure on the Missle Frigate USS Yorktown on September, 1998 paralyzed the cruiser, for at least two-and-a-half hours, the ship was 'dead in the water', about 30+ nautical miles offshore - even comms were down and it needed to be towed in. The "Smart Ship" system was loudly declared a success, then decommissioned.
    http://www.wired.com/science/discoveries/news/1998/07/13987

    2007- The Type 45 U.K. destroyers now being launched will run Windows for Warships: and that's not all. The attack submarine Torbay has been retrofitted with Microsoft-based command systems, and as time goes by the rest of the British submarine fleet will get the same treatment, including the Vanguard class (V class). The V boats carry the UK's nuclear weapons and are armed with Trident ICBMs, tipped with multiple H-bomb warheads.

    there is a reason red china has been targeting all windows systems...

    software bug in the F-22 Raptor stealth fighter. It seems that the computer systems had problems flying West across the International Date Line.

  13. Scott Hedrick
    March 1, 2017 at 3:44 am

    I recall reading about an issue with the Patriot missile that occurred during the first Gulf War. A minor programming error led to a timing error of a few milliseconds per minute. Under designed operating conditions, in which the unit was rebooted every several hours, it was a non-issue. But they were kept on for days at a time in the field during the war, which led to timing being off by several seconds, which meant that the anti-missile defenses were missing targets or had much shorter response times. One incident led to the Patriot being fired a second or so late, which resulted in an interception much closer than intended, and the incoming Scud warhead ended up landing on the US barracks in Riyadh. The irony was, a tape with updated software was literally in the air on its way to Saudi Arabia when the incident happened. This was a combination of a minor software error, failure to properly test, poor specification, and end user not following the instructions. Good software design needs to anticipate user abuse, and in this case, exceeding the intended operating time should have been anticipated and tested.

  14. Doug3000
    February 28, 2017 at 5:42 pm

    My dad was a programmer in the 60's. They knew about the Y2K problem back then, but said, fucck it, we'll be retired by then!

  15. Hildy J
    February 28, 2017 at 1:38 am

    As far as Y2K, it wasn't a bug so much as a design decision, dating to when storage was limited, to reduce every date's storage requirement 25% by omitting the century. Similar decisions include the IPv4 address space and the massive Year 2038 Problem of the UNIX clock. They point out that software infrastructure ages and needs maintenance too.

    The Heartbleed bug, OTOH, is a symptom of a widespread and unforgivable (at least to us retired programmers) practice - not checking the input before you process it. One could also question programming languages which allow buffer overflows and over-reads. These issues were, and still are, the vectors for innumerable pieces of malware.

  16. Matt
    February 27, 2017 at 9:55 pm

    One here in Australia, by an internationally recognised computer supplier and programmer. The new Queensland Health Employee payment system was switched on and the other instantly disabled. For 2 years after, the errors went from people not being paid (in large numbers ) to being underpaid to over paid etc and the company floundering to fix it. A complete stuff up!. It cost millions to buy and millions to try fix before being bunped. It was so bad that company has been banned as a supplier for the Queensland government. I imagine it was going to handle all government pays but they were testing it on the health department !