About my blog

I write about the technical and non-technical aspects of software development

How it works

Microsoft ASP.NETASP.Net
BlogEngine.NET BlogEngine.NET
Azure DevOpsAzure DevOps

Contact info

 Email
 Contact

Follow me

Prod-20240407.1

Where do bugs come from?

Why does software have bugs? How and why do they get into your applications?

Where do bugs come from?

In popular perception bugs are literally mistakes in software; a result of carelessness from software developers or a lack of testing and QA.  Maybe a number needed to be saved to 5 decimal places and instead was only saved to 2 places. So when a calculation is done later, the numbers don't match with expected values.  Perhaps an algorithm representing a business rule was improperly implemented within the code.

We've all had that moment of indignation and frustration using an application where we think 'If only [insert expletive] [insert software company name] wrote better [insert few more choice expletives] software and tested it properly!'.

A fuller definition of a bug is anything in your software that causes a deviation in expected appearance, behaviour or output. That deviation could be trivial: a misaligned image or the wrong font on a header. It could be serious; perhaps crediting the wrong customer account when a button is clicked.

So is it really all down to mistakes and carelessness on the part of people like me?  Well, it's a bit complicated.

Bugs of complexity

Generally speaking, you can be sure that the more complex the software, the more intricate the business rules or behaviours, the higher the potential for bugs.

This can occur either through misunderstanding or as a consequence of the complexity and amount of the resulting code, or failure to anticipate and test every potential input and verify the outcome.

You can be sure that the number of bugs rises in direct proportion to the number of lines of code!

Errors are often the by-product of the design and specification process.

For example, we expect that a user does A, and the application responds with B. Then the user does C, and the application responds with D. But what happens if a user tries to do C BEFORE they do A? Suppose neither developer, testers or the customer consider this possibility when they software is being discussed, developed or tested. When it is discovered later having caused an error, you have a bug!

Bugs can lie in your system for a long time - even years before they surface. A line of code may only be executed when a very particular set of circumstances arise, such as a leap year, or when an input includes very specific set of values in a particular order - or both!

At other times a design decision or feature can become a bug!

Undercover bugs

Sign showing incorrect year as result of Millenium bug

In the early years of computing, memory was expensive. Developers decided they could save memory by using just 2 digits to store the year in all dates.

However, as we approached the year 2000, there was concern about a worldwide computer meltdown caused by what became known as the Millennium Bug, where computers would get 'confused' about the meaning of the 2-digit year: would '20' mean 1920, or 2020?

In a similar way, your software developers may decide to make certain choices for your application that are harmless or pragmatic now, but could become a bug later.

Bugs from the outside!

Bugs can be exposed by apparently unrelated changes to the environment on which you run your application, leading to users scratching their heads thinking 'But, it was working fine yesterday!'.

Getting a shiny new computer is great from a performance and security perspective. However, your application, particularly if it is a few years old, is unlikely to have been tested on the new computer's hardware and software. The software may not run reliably on your new computer and you may have errors or even system crashes as a result.

In some cases upgrading your operating system, installing a security update, updating a malware or antivirus program or even your your web browser can make your software behave differently.

If your application gets data from other systems then bugs or changes in other systems can have a knock-on effect on your application.

For example, you may have regularly been importing a file into your database for years until one day it throws an error. It turns out that the input file format has been changed - the fields are in a different order. Or it now uses letters and digits in a field which previously only took digits, and your application code didn't pre-empt this possibility. 

There again, your application has the bug - even though there is not  'error' in your system.

So now we know where bugs come from, what can we do about them?  

That will be the subject of my next post!

 

 


You Might Also Like


Would you like to share your thoughts?

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

Comments are closed