On September 9th, 1947 a team at Harvard was working on their Mark II computer, when it began to given them unexplained errors over and over.

They decided to open the hardware to see what was wrong and they found a moth was interrupting the electrical flow of the computer.

Thus the term software bug, was born.

As technology has advanced, the days have passed where an adventurous moth is likely to interfere with the performance of your software.

So before we talk about what modern bugs look like and why they still happen, it’s important to define what a bug is.

Here’s a definition we liked from techopedia:

A problem causing a program to crash or produce invalid output… caused by insufficient or erroneous logic. A bug can be an error, mistake, defect or fault, which may cause failure or deviation from expected results.

In the 1940’s, these types of issues generally originated from the hardware of the computer malfunctioning, but as hardware has become increasingly advanced, more often than not, the issue comes from the software.

And software bugs can have some serious consequences.

Take for instance a few of the most famous bugs called “Y2K”, also known as the Millennium bug, was a computer programming problem that arose in the late 1990s due to the way that computer programs and systems were designed to handle dates.

At the time, many computer programs were designed to use two-digit representations for years (e.g. "97" instead of "1997"), in order to conserve memory and reduce data storage requirements.

As the year 2000 approached, many people became concerned that computer systems would not be able to distinguish between the year 2000 and the year 1900, leading to potentially disastrous consequences.

For example, financial systems might incorrectly calculate interest or payment schedules, while utilities and transportation systems might fail to operate correctly.

To address the Y2K bug, software developers and system administrators had to update or replace many computer programs and systems to ensure that they could properly handle dates beyond the year 1999.

This effort required significant time and resources, and was estimated to have cost organizations worldwide billions of dollars.

Ultimately, the Y2K bug did not cause as much disruption as some had feared, due in part to the extensive preparation and testing that went into addressing the issue.

However, the Y2K bug served as a wake-up call for many organizations and highlighted the importance of anticipating and addressing potential programming problems and bugs before they become critical issues.

Why bugs have been so pesky to eliminate even as programming languages and the software used to find and destroy them have advanced, is because of a few fundamental reasons:

1. Humans still write most code: Humans have a hard time comprehending full software systems, and are prone to making mistakes, not being able to anticipate how things will affect each other or just general oversights.

2. Software Testing Limitations: Even the best developers who write tests into an app and are constantly iterating off of what they find can run into limitations on how the types of usage they can replicate.

3. Third Party Dependencies: Most software built these days is built off of other people’s platforms and code, so even if you write really clean code, there can be outside forces that cause your app to break in unanticipated places.

(Here’s a video of a Widows bug, which is very satisfying for those of us who are Apple people…)

Code Reviews

A code review is a software development process in which one or more developers review the code written by another developer or team.

The goal of a code review is to identify potential issues or bugs in the code and to provide feedback that can help improve its quality.

Code reviews can be done manually or with the help of automated tools. During a manual code review, a reviewer reads through the code and examines it for potential issues, such as logical errors, security vulnerabilities, and performance problems.

Automated tools can be used to assist with code reviews by analyzing the code for potential issues, such as syntax errors, unused variables, and inconsistent code formatting.

Unit Testing

Unit testing is a software testing technique in which individual units or components of a software application are tested in isolation from the rest of the application.

The purpose of unit testing is to identify and isolate bugs in a specific unit of code before it is integrated with other units of code or the application as a whole.

Unit testing typically involves writing test cases for each unit of code that is being tested.

These test cases are designed to exercise specific functions or methods within the unit, and to verify that the unit behaves as expected under different scenarios and conditions.

Unit tests are typically automated, which means that they are executed automatically each time a change is made to the code, to ensure that the change did not introduce any new bugs or issues.

Unit tests are also frequently run as part of a continuous integration and deployment (CI/CD) pipeline, which helps ensure that changes to the codebase are tested and validated before they are deployed to production.

Integration Testing

Integration testing is a software testing technique that focuses on testing the interactions and integration between different components or modules of a software system.

The purpose of integration testing is to ensure that different components work together as intended and to identify any defects or issues that may arise when different components are combined.

Integration testing typically involves combining two or more units of code or modules and testing them as a group. Integration tests are designed to validate that the interactions between the components are correct and that data is properly passed between them.

Integration tests can also be used to identify and resolve issues related to data flow, data storage, and data transformation.