Interesting facts about software "bugs"

If there is one thing that a programmer knows, it is the term "bugs" when it comes to their code not functioning as intended. Maybe in your own code, or maybe in someone else's. Probably someone else's. Something that didn't quite render correctly or maybe causes the software to stop running or even worse goes unnoticed.

At least that's the most common definition that most people have these days when it comes to software bugs. But what exactly are they? Is it just poor code written by a tired or inexperienced dev, or maybe hardware not keeping up well with the demands, or maybe even a user  clicking on the wrong button (user error).

Let us dive deep into this keyword that we throw about so loosely today and get a little more clarity on the whole thing, because bugs deserve some attention sometimes too.

A quick background before we start. The term "bug", as it relates to a computer system error, first came to be used during the 1940's when computer pioneer Grace Hopper^[1], while working on the Mark II computer, found a month trapped in the system, which caused it to fail. They found a literal "bug". While that isn't the first occurrence of the term being used to describe an "error", it is one of the first to be used to describe a computerized error.

0: "Bugs" typically run on production code

Bugs run on production code and on production servers for the most part. Code that was pushed with the expectation that everything will work as described, however with unexpected results to the front-end users. Maybe the data comes back corrupted or perhaps after 149 hours, the system needs to be shut down and restarted. Bugs require the person using it to pretty much state why it isn't working, otherwise, it isn't a bug just yet.

And If it's still in the development phase or a test server then it is best to avoid calling it a "bug" and calling it an item on your to-do list instead. And this is a key feature of 'bugs' and one that makes them troublesome. They are expected to not exist and yet by some combination of variables and edge cases, they spring to life.

1: Some bugs can take years to find

Some bugs aren't noticeable until something triggers them to jump out and scream at your error logs. And sometimes, this can take a good while to occur. Most bugs that you hear about in the news probably took place years before they were announced to the public, it's just that they were only now getting around to telling you about it, or as mentioned above, to being found. Much of this has to do with the fact that most software matures as it grows and scales in size. Hundreds of lines of code turn to thousands turn to tens of thousands and so on. And this makes it difficult to track changes in the long term without some form of proper documentation or code maintenance process in place.

Various software solutions exist for creating test cases that you can automatically run against your code, and this has been hugely beneficial during the past few years as technology enters into our daily lives and becomes entangled with it. Software like nUnit for .NET for example or Selenium for testing web applications have played a huge role in making the software that we use daily more sustainable.

However, this is not a perfect solution to finding inherent errors within business processes. If the system is not working as the designer intended, regardless of it not crashing or not, then it has bugs.

Another reason that bugs pop into existence later in our timelines, is because they might not be bugs today. It is possible that by all sense and purpose the software works as intended given our current technology and understanding of it. But due to new discoveries later on and new hardware and software being released, that this once functional system can appear to not be functioning anymore.
And in that same manner, new people take over projects all of the time and the understanding or vision that they have for it might not match the one of the former person in charge.

2: They can have serious effects

Sometime during the 80's a computer-controlled radiation therapy device named the Therac-25^[2] was being used on the public with an inherent bug in its system that went unnoticed for some time. Did this bug cause the machine to blink a blue screen before restarting, or leak data (somehow)? It did not. But it did inadvertently give at least 6 patients incredibly high doses of radiation therapy causing injury to their overall health. This was not a hardware issue, as we would find out eventually, but was instead blamed on a faulty design and architecture.

The device itself had various settings for the computer controlled flow of electrons, including a test mode. The bug occurred when the person driving the device accidentally chose the wrong setting before switching to the correct one. This resulted in the machine dosing out hundreds of times more energy than was intended. Previous versions of the device relied on physical fail safes to prevent such incidences from occurring. The new design for the Therac-25, however, removed those checks in favor of a more software based solution.

You can read more about the Therac-25 case here if interested. This particular case-study is covered in various university courses and academic textbooks in the Computer Science field in order to shed light about the ethics of being a software engineer and the effects that improper code can have.

3: Most bugs aren't related to code

It may sound weird to say, especially on a blog about coding, but most software errors are not related to the code itself. Most software bugs that I've encountered in the professional world have had more to do with the humans that were creating the business processes and designs then with the code itself. Errors inherent in the system and architecture in which the code did as specified in the specifications, however it did not match the desired outcome that someone had.

If you are programmer, then hopefully you find some ease with the following. The number of times that a project manager has approached me with an email about a proposed bug in the system, which inevitably costs me the developer hours of extra work and stress, only to realize that everything was working fine and the user had either entered invalid data or, even worse, didn't know what result to expect, was countless. This is where the developer joke of "user-error" comes from. Which is why good part of a software developer's day to day does in fact consist of validation and error checking. If a box says "numbers only please", rest assured that someone somewhere will type "one", into that field.

I hope you enjoyed this lower-level look at a term that most programmers throw around loosely and got some further insight into the realm of 'bugs' in our code.

But always test your code...twice.