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, so given a particular set of input values the user is returned something unexpected.

We’ve all had that moment of indignation and frustration using an application where we think ‘If only [insert expletive] [insert 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

A general rule is 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 from 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, consider the following process

1. A user performs an action A

2. The application returns and response B.

3. The user then does C

4. The application responds with D.

What happens if a user tries to do C before A? Will, it still return D after C? Or will it return B? Or something else? Will it crash the application? Suppose nobody considered this possibility when the software was being discussed, developed or tested. When it is discovered later having caused an error, you have a ‘new’ 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 input includes a 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

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 Millenium 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 operating system. 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 web browser can make your software behave differently. If your application gets data or relies on processes from other systems, bugs or changes in those 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 preempt this possibility. There again, your application has the bug – even though there is no actual ‘error’ in your system.

Daishik Chauhan Crucis Consulting

Daishik Chauhan is a full-stack contract software developer, software and IT consultant, and Microsoft Azure solutions architect. Through his company, Crucis Consulting Limited,

Daishik specialises in technical and business analysis, delivery planning and coordination, and Microsoft database and software consultancy.

07949 243306 info@crucisconsulting.co.uk crucisconsulting.co.uk