History’s Worst Software Error: Top 9 Disasters

Imagine if every glitch in your video game made it crash spectacularly – it would be a disaster, right? Now think bigger: what if a tiny mistake in a piece of software could cause millions in losses, risk lives, or even change history? This isn’t the plot of a science fiction movie; it’s the reality of history’s worst software error and other significant bugs in software. These software failures are not just simple oops moments; they are monumental miscalculations that underscore the critical importance of meticulous software development and testing.

As we delve into the heart of our story, we will uncover some of the most jaw-dropping blunders in the tech world. From the terrifying Therac-25 incident, the simple yet expensive mistake that led to the loss of Mariner 1, to the infamous Y2K bug that had us all holding our breath as the millennium turned. We’ll look at the explosive failure of the Ariane 5 rocket, the oversight in the Mars Climate Orbiter’s mission, and even a math blunder in the Intel Pentium processor that went viral. Each software bug tale highlights the biggest software failures in history and teaches invaluable lessons. Buckle up; it will be an educational ride through the world of computer bugs, exploring how even the smallest software failure can lead to some heavyweight software disasters.

The Therac-25 Incident (1985-1987)

Overview of Therac-25

The Therac-25, a radiation therapy machine developed by AECL in the 1980s, was a groundbreaking device due to its dual treatment modes, which allowed it to switch between low-energy electrons and high-energy X-ray photons. This feature made it possible to treat different types of cancer within the same session, revolutionizing cancer treatment by reducing the need for multiple machines and simplifying patient logistics. The machine’s reliance on software-based safety systems instead of traditional hardware controls marked a significant shift in medical device design.

Description of the Error

Tragically, the Therac-25’s innovative design also led to its downfall. The software switching between the low and high-power modes contained a critical bug. This error was a race condition that had been inadvertently copied from an older model, the Therac-20, where it had been harmless due to additional hardware safety checks not present in the Therac-25.

Screenshot from Therac 25 interface simulation. By Software compiled from source code available at, Copyrighted free use, Link

This software flaw allowed the high-power X-ray mode to activate without the necessary hardware in place, delivering lethal radiation doses to patients. Specifically, if the operator made a rapid sequence of inputs, the software would fail to update the machine’s settings correctly, misleading the operator about the current mode.

Consequences

The consequences of this software error were catastrophic. Between 1985 and 1987, the Therac-25 was linked to at least six accidents where patients received up to 100 times the intended dose of radiation, leading to deaths and serious injuries. These incidents underscored the dangers of relying solely on software for safety-critical functions in medical devices. The Therac-25 case has since become a seminal example in discussions about software safety and ethics in engineering, highlighting the critical need for comprehensive testing and regulatory oversight in medical device software.

The aftermath of these events led to significant changes in how medical devices were designed and regulated, particularly concerning the role of software in safety-critical systems. The Therac-25’s legacy is a sobering reminder of the potential human cost of software errors in complex systems.

Mariner 1 Space Probe (1962)

What Happened

Mariner 1, part of America’s early attempts to explore Venus, faced a disastrous end due to a small but critical software glitch. Launched on July 22, 1962, this spacecraft was meant to collect scientific data during a flyby of Venus. However, 293 seconds after launch, a range safety officer had to issue a destruct command because the spacecraft began veering off course due to an unscheduled yaw-lift manoeuvre. The root cause? A missing hyphen in the guidance software’s coded instructions led to incorrect steering commands sent to the spacecraft. This tiny error in the code caused the rocket to behave erratically, ultimately leading to its destruction.

Impact and Cost

The failure of Mariner 1 was not just a setback regarding mission objectives but also a financial blow. The mission’s total cost was reported to be around $18.5 million, which, adjusted for inflation, amounts to about $186 million today. This incident highlighted the high stakes in space exploration, where even the smallest oversight can lead to monumental financial losses and delays in scientific advancements.

Lessons Learned

The Mariner 1 incident served as a crucial learning point for NASA. It underscored the importance of thorough pre-launch debugging of software and the need to engineer programs so that minor errors do not lead to catastrophic failures. This experience led to significant improvements in NASA’s software verification processes, which later ensured the success of several Apollo lunar modules landing on the Moon despite minor software bugs. The incident also highlighted the pressures of the Space Race, pushing NASA to refine its spacecraft designs and operational protocols to prevent such costly errors in the future.

The Y2K Bug (1999-2000)

Background and Causes

The Y2K bug, often referred to as the millennium bug, was a coding quirk that had the potential to send computer systems into a tailspin at the stroke of midnight, January 1, 2000. This bug stemmed from how dates were formatted in computer systems; years were abbreviated to the last two digits to conserve valuable memory space, making the year 2000 indistinguishable from 1900. Initially, this might not sound like a big deal, but imagine your computer thinking it’s time to party like it’s 1899, not 1999!

Concerns and Predictions

As the 20th century drew to a close, the potential impacts of the Y2K bug ranged from minor glitches to catastrophic failures in sectors heavily reliant on date-sensitive systems. There was a real fear that financial systems could collapse, utilities could fail, and planes might fall from the sky if the bug wasn’t fixed. Governments and businesses worldwide braced for potential chaos, with the United States alone spending an estimated $100 billion on preparations. This colossal effort was aimed at reviewing and repairing millions of lines of computer code.

Actual Impact

When the clock struck midnight on January 1, 2000, the world held its breath… and then breathed a collective sigh of relief. The anticipated widespread disruptions largely failed to materialise thanks to the extensive global preparations. There were a few hiccups, such as a nuclear energy facility in Japan facing minor issues, but nothing threatening public safety. In the aftermath, the Y2K bug was frequently ridiculed as a non-event, leading to debates about whether the immense efforts to avert disaster were justified. However, those involved in the fixes maintained that these efforts ensured the new millennium began not with a bang but with a whimper.

In essence, the Y2K bug turned out to be a bit like studying for an exam that got cancelled—frustrating but ultimately a lot less disastrous than it could have been. The extensive preparations may have seemed over the top, but they likely saved us from starting the 21st century in a full-blown tech meltdown. So, next time you update your software, remember the Y2K bug and consider it a small price to pay for keeping our digital world on track!

Ariane 5 Rocket Explosion (1996)

Description of the Error

On June 4th, 1996, the Ariane 5 rocket, designed to propel communication satellites into orbit, faced a catastrophic failure 40 seconds after lift-off. The primary cause? A software glitch in the rocket’s Inertial Reference System. This system, crucial for determining the rocket’s orientation, failed dramatically when it attempted to convert a 64-bit floating-point number, representing the rocket’s horizontal velocity, into a 16-bit signed integer. This mismatch led to an overflow error because the larger number couldn’t fit into the smaller data type. As the rocket accelerated, this conversion error overwhelmed the system, causing the onboard computer to shut down and the rocket to veer off its intended course.

Immediate Effects

The immediate aftermath was as dramatic as a scene from a blockbuster movie but far from fictional. Just 37 seconds into its journey, the rocket flipped 90 degrees in the wrong direction. Within seconds, the aerodynamic forces tore the boosters from the main stage at an altitude of about 4km, triggering the self-destruct mechanism and resulting in a massive explosion. The rocket debris rained over approximately 12 square kilometres near the launch site. This explosion destroyed the rocket and resulted in a loss of over $500 million in equipment and years of research.

Long-Term Consequences

The fallout from the explosion was extensive, affecting more than just the financial books. The failure highlighted significant flaws in the software testing and validation processes used at the time. Investigations revealed that the error could have been detected through more rigorous testing, particularly the inertial reference system and the complete flight control system. In response, the European Space Agency implemented several corrective measures to prevent such disasters in the future. These included improvements in software testing, the introduction of redundancies in the testing processes, and a critical reappraisal of all flight and embedded software. The Ariane 5 disaster is a stark reminder of the importance of comprehensive system testing, particularly when transitioning to new technology platforms involving significant system design and operation changes.

The Dhahran Patriot Missile Failure (1991)

Details of the Incident

On February 25, 1991, during Operation Desert Storm in Dhahran, Saudi Arabia, a significant software error led to a tragic event involving the Patriot missile defence system. This system, originally not designed to intercept Scud missiles, failed to track and intercept an incoming Scud missile. As a result, the missile struck an Army barracks, causing the loss of 28 American lives. This incident occurred because the Patriot missile’s weapons control computer experienced a critical flaw in its software. The software inaccurately calculated the tracking of incoming missiles, a problem that worsened the longer the system was operational.

Underlying Issues

The root of the problem lay in the system’s timekeeping. The Patriot missile system used a 24-bit floating point register to calculate time, converting the time from tenths of a second to seconds for tracking calculations. However, due to rounding errors in these conversions, there was a gradual degradation in the accuracy of the system’s “range gate,” the critical component that locates and tracks the target. By the time of the incident, the system had been running continuously for over 100 hours, exacerbating the error to a point where the system could no longer track the incoming Scud accurately. Interestingly, army officials developed and released modified software that could have corrected this error on February 16. Still, it did not reach Dhahran until February 26, 1991—unfortunately, the day after the tragic incident.

Repercussions

The failure of the Patriot missile system in Dhahran had immediate and severe consequences, not only in terms of human casualties but also in highlighting significant vulnerabilities in military defence technologies. The incident underscored the critical importance of accurate software functioning within military systems, particularly those involving ballistic missile defence. Following this event, there was a concerted effort to enhance software reliability and accuracy, ensuring that time calculations were precise and that systems could operate effectively over extended periods without degradation in performance. This event also served as a stark reminder of the potential human cost associated with dependencies on complex software systems in critical military applications.

Mars Climate Orbiter (1998)

Mission Overview

Launched on December 11, 1998, the Mars Climate Orbiter was designed to study the Martian climate and atmosphere from orbit. Its mission was not just about gathering scientific data; it also aimed to act as a communications relay for the Mars Surveyor ’98 program, supporting the Mars Polar Lander. The orbiter, a 638-kilogram robotic space probe, represented a significant investment, costing $125 million. Imagine the excitement and anticipation of the NASA team as they launched this sophisticated piece of technology, hoping to unveil the secrets of Mars’ atmosphere and possibly find signs of water vapour.

Nature of the Error

However, the mission encountered a critical error that led to its failure. The problem arose from a classic ‘lost in translation’ scenario between two measurement systems. The Jet Propulsion Laboratory (JPL) navigation team used the metric system for their calculations. In contrast, Lockheed Martin Astronautics, the contractor responsible for the spacecraft’s construction, used the English system. This mix-up in units led to incorrect calculations of the spacecraft’s trajectory. Specifically, the software controlling the orbiter’s thrusters calculated the force needed in pounds. In contrast, another software reading this data assumed it was in newtons per square meter. It’s like baking a cake with all the right ingredients but in the wrong quantities—disaster is inevitable!

Outcome

The outcome was as dramatic as it was unfortunate. On September 23, 1999, just as the Mars Climate Orbiter was supposed to enter Martian orbit, it came too close to the atmosphere. It disintegrated due to intense friction from atmospheric drag. This error resulted in the loss of the spacecraft and a waste of the $125 million invested in the mission. The subsequent investigation highlighted severe flaws in the mission’s engineering and operational checks. It turned out that the error could have been detected with more rigorous testing and better communication between the teams at JPL and Lockheed Martin. This incident is a stark reminder of the importance of clear communication and stringent checks in space missions, where even the smallest oversight can lead to colossal failures. Imagine this chaos over a simple unit conversion—metric versus English. It’s like telling someone to meet you at 3:00 without specifying am or pm and then wondering why you’re alone!

Intel Pentium Floating-Point Bug (1994)

Error Details

The Intel Pentium Floating-Point Bug, famously known as the FDIV bug, was a significant hiccup in the computing world, affecting the early Intel Pentium processors’ floating-point unit (FPU). Imagine a tiny gremlin in the machine messing up your math homework—that’s what happened here but on a much bigger scale. This bug caused the processor to return incorrect binary floating-point results when dividing certain pairs of high-precision numbers. The root of the problem? A flawed lookup table in Intel’s SRT algorithm missed five crucial entries, leading to miscalculations.

Discovery and Response

The bug was first spotted by Thomas Nicely, a sharp-eyed mathematics professor, who noticed odd results in his prime number calculations. After some detective work, he traced the issue to his new Pentium computer. On October 24, 1994, he flagged this to Intel. Interestingly, Intel was already on the case by then but hadn’t gone public with the information. The bug became a full-blown scandal when Nicely emailed the academic community on October 30, 1994, prompting quick verification and widespread Internet buzz.

Intel’s initial response was a bit like a shrug. They acknowledged the issue but downplayed its severity, offering replacements only to those who could demonstrate they were affected. However, as the negative press snowballed, Intel shifted gears and announced a no-questions-asked replacement policy on December 20, 1994. This decision came after a significant financial hit, with Intel taking a pre-tax charge of $475 million to cover the costs of replacing the flawed processors.

Impact

Despite Intel’s attempts to minimize the situation, the FDIV bug caused quite a stir. It was a PR nightmare that dented Intel’s reputation and highlighted the importance of transparency and customer trust. The bug’s discovery and the subsequent handling of the situation marked a turning point for Intel. They learned a hard lesson on the importance of consumer relations and quality assurance, leading to improved validation methodologies and better communication with end-users. Intel’s “Intel Inside” campaign, which had been building brand recognition, suddenly became a double-edged sword, pointing customers directly to them with their grievances.

This incident is a textbook example of how a small technical flaw can escalate into a significant corporate crisis, reminding us all that a little bug can have a big impact in the digital age. So, next time your computer acts up, just be thankful it’s probably not a multi-million dollar error!

The Morris Worm (1988)

What Happened

On November 2, 1988, the digital world experienced one of its first major shocks when the Morris Worm was unleashed. Created by Robert Tappan Morris, a 23-year-old student from Cornell University, this worm was intended as an experiment to highlight security vulnerabilities but ended up causing widespread chaos. Imagine a cheeky prank that spirals out of control—this was it, but on a massive scale! The worm exploited several weaknesses in UNIX systems, including a hole in the debug mode of the Unix sendmail program and a buffer overflow in the finger network service. It also used the transitive trust commonly set up in network logins, where no password requirements were enforced, making it easier for the worm to spread.

How It Spread

The Morris Worm was quite the digital acrobat. It exploits known vulnerabilities and guesses weak passwords to propagate. The worm contained a list of 900 common passwords and could use the names of account holders to brute-force its way into systems. Its method of verifying if a system was infected made it particularly pesky. If the system were clean, the worm would install itself; if already infected, it would re-infect the system one out of seven times to ensure it stayed entrenched. This approach ensured the worm’s spread and persistence, bogging down systems with multiple instances of itself running simultaneously, severely degrading performance, and eventually leading to system crashes.

Consequences

The impact of the Morris Worm was both immediate and long-lasting. It infected approximately 6,000 computers, a significant number considering the size of the internet at the time, primarily an academic and government network with about 60,000 connected machines. The worm’s spread highlighted the inherent vulnerabilities in networked systems and the need for better security practices. It was a wake-up call that reshaped how cybersecurity was viewed and handled. The Computer Emergency Response Team Coordination Center (CERT/CC) was established to coordinate responses to network emergencies in response to the worm’s release and the ensuing chaos. Moreover, Robert Morris became the first person convicted under the Computer Fraud and Abuse Act, facing fines and probation—a stark reminder of the legal implications of unleashing software that disrupts computer networks.

This incident taught the tech world about the dangers of insufficient network security. It led to a more guarded approach in digital communications, influencing the development of more robust security measures that are crucial even today. So, next time you’re setting a password, make it tough to crack—take a lesson from the Morris Worm and keep those digital pests out!

The Morris Worm, unleashed on November 2, 1988, by Robert Tappan Morris, a 23-year-old student from Cornell University, was intended as an experiment to highlight security vulnerabilities but ended up causing widespread chaos. An interesting and less-known fact about this incident is that the Morris Worm was not intended to be as destructive as it was. Morris intended it to gauge the size of the internet simply. However, due to a programming error, the worm ended up replicating itself excessively, leading to a rapid spread and causing significant slowdowns in thousands of computers across the early internet. The incident brought attention to the vulnerabilities of interconnected computer systems and the need for robust security measures in the digital age.

The Knight Capital Group Trading Loss (2012)

Incident Overview

On the morning of August 1, 2012, Knight Capital Group, a titan in American financial services known for its extensive market-making and electronic execution operations, faced a calamity that almost obliterated its business within an hour. A flawed deployment of new trading software triggered a frenzy of unintended stock purchases totalling around $7 billion. This software glitch, which went live with the opening of the New York Stock Exchange, led Knight on an unintended buying spree across 150 different stocks.

Technical Details

The root of the disaster was a seemingly innocuous oversight during the software update process. Knight Capital’s automated routing system for equity orders, known as SMARS, was updated to include a new Retail Liquidity Program (RLP) code. However, this update was incomplete, leaving one of the eight servers with the old code active. Still running the outdated ‘Power Peg’ function, this server misinterpreted incoming legitimate orders and initiated repeated erroneous transactions. The defective code caused the system to buy stocks at high prices and sell at progressively lower prices, leading to a massive accumulation of unwanted positions.

Financial Impact

The financial ramifications were staggering. Knight Capital’s erroneous trades amassed a net long position of approximately $3.5 billion and a net short position of about $3.15 billion in various stocks, all within 45 minutes. When the error was discovered, the firm faced an unavoidable loss as it had to offload these positions, resulting in a pre-tax loss of $440 million. This debacle plunged the company’s stock by over 70% and severely dented its capital reserves, threatening its operational viability. The firm’s struggle for survival led to a crucial $400 million cash infusion from investors just a week later, ultimately culminating in its acquisition by Getco LLC the following year.

This incident is a stark reminder of the perils of technological oversights in high-stakes financial environments. It underscores the necessity for rigorous software testing and operational checks to prevent such costly errors.

Conclusion

Through the rollercoaster ride of digital debacles and spectacular software, snafus recounted in our journey, we’ve unveiled the monumental miscalculations that rocked the tech world, from the deadly errors of the Therac-25 to the costly confusion of the Mars Climate Orbiter’s unit mix-up. Each tale, akin to a plot twist in a tech-themed thriller, underlines a universal truth – in the intricate dance of bits and bytes, even the tiniest misstep can lead to a domino effect of disastrous proportions. The narrative not only serves as a cautionary tale but also as a spotlight on the invaluable lessons learned in the crucible of crisis, emphasizing the quintessential role of meticulous testing, the unforgiving nature of oversight, and the ever-present need for clear communication among tech titans and teams alike.

Reflecting on these technological tales of woe, it becomes evident that behind every headline-hitting mishap lies a kernel of knowledge, a lesson hard-earned in the unfathomable complexities of software development. As we forge ahead into the future, armed with the hindsight of history’s harshest lessons, let us channel our collective ingenuity towards creating more resilient systems balanced on the pillars of rigorous testing and transparent communication. So, as we bid adieu to the ghosts of glitches past, let’s commit to a tech-savvy tomorrow where such software sorrows are but whispers in the winds of history, signifying our journey from calamity to clarity in the digital domain.

FAQ

References

Show links

[1] – https://www.youtube.com/watch?v=Ap0orGCiou8
[2] – https://www.wired.com/2005/11/historys-worst-software-bugs/
[3] – https://raygun.com/blog/costly-software-errors-history/
[4] – https://en.wikipedia.org/wiki/Therac-25
[5] – https://ethicsunwrapped.utexas.edu/case-study/therac-25
[6] – https://onlineethics.org/cases/therac-25/history-introduction-and-shut-down-therac-25
[7] – https://en.wikipedia.org/wiki/Therac-25
[8] – https://ethicsunwrapped.utexas.edu/case-study/therac-25
[9] – http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html
[10] – https://www.bugsnag.com/blog/bug-day-race-condition-therac-25/
[11] – http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html
[12] – https://en.wikipedia.org/wiki/Therac-25
[13] – https://science.nasa.gov/mission/mariner-1/
[14] – https://timeandnavigation.si.edu/navigating-space/challenges/mariner-1-destroyed
[15] – https://en.wikipedia.org/wiki/Mariner_1
[16] – https://www.edn.com/mariner-1-destroyed-due-to-code-error-july-22-1962/
[17] – https://raygun.com/blog/costly-software-errors-history/
[18] – https://www.slashgear.com/1101785/this-simple-programing-error-cost-nasa-18-million/
[19] – https://timeandnavigation.si.edu/navigating-space/challenges/mariner-1-destroyed
[20] – https://science.nasa.gov/mission/mariner-1/
[21] – https://www.edn.com/mariner-1-destroyed-due-to-code-error-july-22-1962/
[22] – https://education.nationalgeographic.org/resource/Y2K-bug/
[23] – https://en.wikipedia.org/wiki/Year_2000_problem
[24] – https://www.britannica.com/technology/Y2K-bug
[25] – https://time.com/5752129/y2k-bug-history/
[26] – https://en.wikipedia.org/wiki/Year_2000_problem
[27] – https://blogs.gwu.edu/umpleby/forecasts-of-y2k-consequences/
[28] – https://education.nationalgeographic.org/resource/Y2K-bug/
[29] – https://en.wikipedia.org/wiki/Year_2000_problem
[30] – https://www.britannica.com/technology/Y2K-bug
[31] – https://en.wikipedia.org/wiki/Ariane_flight_V88
[32] – https://www.esa.int/Newsroom/Press_Releases/Ariane_501_-_Presentation_of_Inquiry_Board_report
[33] – https://cordis.europa.eu/article/id/19509-ariane-5-explosion-caused-by-fault-in-main-engine-cooling-system
[34] – http://sunnyday.mit.edu/nasa-class/Ariane5-report.html
[35] – https://www.bugsnag.com/blog/bug-day-ariane-5-disaster/
[36] – https://dl.acm.org/doi/pdf/10.1145/251880.251992
[37] – https://www.bugsnag.com/blog/bug-day-ariane-5-disaster/
[38] – http://sunnyday.mit.edu/nasa-class/Ariane5-report.html
[39] – https://medium.com/@mertaktas1283/ariane-disaster-the-tragic-consequences-of-neglecting-software-testing-80dd7c82cd01
[40] – https://apps.dtic.mil/sti/citations/ADA344865
[41] – https://www.gao.gov/products/imtec-92-26
[42] – https://www.cs.unc.edu/~smp/COMP205/LECTURES/ERROR/lec23/node4.html
[43] – https://www.cs.unc.edu/~smp/COMP205/LECTURES/ERROR/lec23/node4.html
[44] – https://www.gao.gov/products/imtec-92-26
[45] – https://cs.nyu.edu/exact/resource/mirror/patriot.htm
[46] – https://www.gao.gov/products/imtec-92-26
[47] – https://www-users.cse.umn.edu/~arnold/disasters/patriot.html
[48] – https://apps.dtic.mil/sti/citations/ADA344865
[49] – https://science.nasa.gov/mission/mars-climate-orbiter/
[50] – https://www.jpl.nasa.gov/missions/mars-climate-orbiter
[51] – https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
[52] – https://science.nasa.gov/mission/mars-climate-orbiter/
[53] – https://www.simscale.com/blog/nasa-mars-climate-orbiter-metric/
[54] – https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
[55] – https://spacemesmerise.com/en-us/blogs/planets/the-costly-mistake-of-metric-units-lessons-learned-from-the-mars-climate-orbiter
[56] – https://www.simscale.com/blog/nasa-mars-climate-orbiter-metric/
[57] – https://science.nasa.gov/mission/mars-climate-orbiter/
[58] – https://en.wikipedia.org/wiki/Pentium_FDIV_bug
[59] – https://www.cs.earlham.edu/~dusko/cs63/fdiv.html
[60] – https://www.techradar.com/news/computing-components/processors/pentium-fdiv-the-processor-bug-that-shook-the-world-1270773
[61] – https://en.wikipedia.org/wiki/Pentium_FDIV_bug
[62] – https://www.techradar.com/news/computing-components/processors/pentium-fdiv-the-processor-bug-that-shook-the-world-1270773
[63] – https://www.crn.com/news/components-peripherals/229400535/lessons-learned-pentium-flaws-aid-intel-in-sandy-bridge-chipset-recall
[64] – https://en.wikipedia.org/wiki/Pentium_FDIV_bug
[65] – https://ethics.csc.ncsu.edu/risks/reliability/pentium/study.php
[66] – https://www.techradar.com/news/computing-components/processors/pentium-fdiv-the-processor-bug-that-shook-the-world-1270773
[67] – https://www.fbi.gov/news/stories/morris-worm-30-years-since-first-major-attack-on-internet-110218
[68] – https://en.wikipedia.org/wiki/Morris_worm
[69] – https://www.hypr.com/security-encyclopedia/morris-worm
[70] – https://blog.barracuda.com/2023/06/06/malware-101-worms
[71] – https://www.fbi.gov/news/stories/morris-worm-30-years-since-first-major-attack-on-internet-110218
[72] – https://www.okta.com/identity-101/morris-worm/
[73] – https://www.okta.com/identity-101/morris-worm/
[74] – https://www.hypr.com/security-encyclopedia/morris-worm
[75] – https://www.fbi.gov/news/stories/morris-worm-30-years-since-first-major-attack-on-internet-110218
[76] – https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html
[77] – https://medium.com/@alexponomarev/deploy-gone-wrong-the-knight-capital-story-984b72eafbf1
[78] – https://www.cio.com/article/286790/software-testing-lessons-learned-from-knight-capital-fiasco.html
[79] – https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html
[80] – https://dealbook.nytimes.com/2012/08/02/knight-capital-says-trading-mishap-cost-it-440-million/
[81] – https://www.finextra.com/newsarticle/23948/knight-capital-blames-tech-glitch-for-stock-market-chaos-faces-440m-pre-tax-loss
[82] – https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html
[83] – https://en.wikipedia.org/wiki/Knight_Capital_Group
[84] – https://www.tradersmagazine.com/departments/brokerage/the-rise-and-fall-of-knight-capital-buy-high-sell-low-rinse-and-repeat-2/
[85] – https://raygun.com/blog/costly-software-errors-history/
[86] – https://www.newscientist.com/gallery/software-bugs/
[87] – https://www.worksoft.com/corporate-blog/top-software-failures