Let There Be Bugs: Understanding One of Software's Greatest Challenges

By Adam Lifshitz — Executive Director of Product,

It’s June 4th, 1996. The $370 million Ariane 5 rocket launches, and within only 30 seconds begins to disintegrate and thereafter explodes. How did it happen? A small software bug that occurred when the software attempted to transform a 64-bit variable with decimals into a 16-bit variable without decimals led to a series of other bugs and paralyzed the rocket’s systems.

In 1998, NASA’s Mars Climate Orbiter failed to stabilize its orbit and got lost in space, a fatal accident that cost over $300 million. The cause? A small code error by the engineering team that failed to make a simple conversion from English units to metric. And, less than a year ago, Microsoft released the now infamous Windows 10 October 2018 update which led to the permanent deletion of personal files for hundreds of early users, some losing over 20 years of documents, pictures, videos and more.

Schedule a Demo

These are but a few catastrophic events that were initiated by bugs in software, built by reputable companies with massive funding and immensely experienced engineering teams. Suffice to say, any software built by any company comes with its fair share of bugs and their level the impact ranges depending on the software and situation.

Question is: Should we, as users and creators of software alike, accept it as the ‘nature of the industry’ or are we to expect more?

If you’ve guessed by the title, my answer would be to accept that bugs are not only common, but are also here to stay.

To understand why bugs occur in the first place, we need to better understand software development. It is perhaps one of the most complex industries out there. As a science in its own right, not only did we build incredible hardware to advance us technologically, we've also created languages and tools to control it to do the things we want to do. It’s a wonderful space full of unlimited potential, but even decades down the line, it’s a space we are still learning and growing in.

Like other forms of science, be it medicine, biology or chemistry, it is founded upon experimentation. As software builders, we are continuously attempting to create something new, try something out, solve a new problem or cater for an unfulfilled need. To do so, we look at our toolset - coding languages and frameworks we’re familiar with, or even ones that we have yet to learn - and we try to tell a machine to do something that it hasn’t done before. Many of the times, no one else has done it either, or at least not within the context of our own software, so we have no point of reference.

Imagine knowing how to speak German for only two years and now you have to run a restaurant in Berlin, with all its intricacies and German-speaking staff. Undoubtedly, you’re going to run into some hurdles and although you can do as many dry runs and preparations as you’d like, some of these hurdles will only come to light when you have real customers at your place.

Software is much of the same; here at, we have a range of people in different roles and levels of expertise whom are familiar with different toolsets and languages that are trying to work together to build things that they may have never built before. Sometimes the task is small and clear and is thus approached with absolute confidence, and sometimes we are trying something out and just hope it works.

As a line of defense, we have people that are responsible for quality assurance (QA) and testing, ensuring another opportunity to test that the work meets its initial expectations prior to it being used by the end-user. We’ve also created tools and ways to automate that process. And yet, every now and then, some bugs are not identified no matter the amount of people working and testing the software, and users are displeased (usually to a small degree rather than to a catastrophic extent).

The important thing to remember, and the reason for all of this, is that software development (much like anything else we do), is subject to human error.

Accepting that humans are not perfect and make mistakes is a non-argument; it’s in our nature, and we all go through it. Some may say that while we can expect error from humans, software is machine-based so it cannot make human errors and is thus safer and more reliable. But guess who’s writing that software? Humans!

No matter how many years of experience you have as a software engineer, QA tester, product manager or system architect, you are subject to human error. Even with the most outstanding skillset, and the multi-layered testing processes you have set in place, you are still subject to human error. And as long as there is human error, and as long as we continue to experiment with new tools and programs and incredible software that makes each of our lives a little bit better - there will be bugs.

So maybe it’s time to say, Let There Be Bugs, and learn to be more understanding when they do occur, provided that we didn’t lose a spaceship or anything like that. As concluding entertainment, here’s Bill Gates presenting Windows 98 live and then getting hit by the famous Blue Screen of Death :)

Screen Shot 2018-12-18 at 10.21.04 AM Adam Lifshitz is our Executive Director of Product at Originally hailing from Cape Town South Africa, he moved to New York in 2017 to continue his career in leading teams to build successful software products. He carries over seven years of experience in the digital industry, and holds a Bachelor of Commerce in Management Studies. He’s particularly meticulous about process and efficient ways of collaborating with people to achieve goals, in business and otherwise. 

Subscribe to the Insights blog




Event Management Software: A Blessing and a Curse

Solving Product Design Challenges with a View

Building a Seating Tool... Together