Embracing the facts - software have errors

Published by Michael Banzon on Mon Jan 1, 2018

Errors in software is one of those things that can be frustrating and it can lead to trouble - both internally and externally - for software development teams. Getting in control is key to success - both for the team and the users!

Software is complex. The processors in modern computers tick away executing billions of instructions every second - all of these are written (directly or indirectly) by humans - and as we know humans do make mistakes.

A normal functional piece of software might contain (even multiple) hundred thousand lines of code (translating into billions of instructions) - it as inevitable that some of these contain errors and therefore the chances are that users of the software will experience errors during normal use.

Types of errors

Errors made by programmers come in different flavours. Please consider this short list:

  • Visible errors - these manifest in primarily in the user interface and usually leads to raised eyebrows from users but most of them leave the program in a usable state - stuff just looks funny. In this category we also see spelling and localisation errors.
  • Crashing errors - these are also noticed very easily by the user. They will make the program halt and crash - depending on the OS running the program this might give a message to the user that is more or less understandable - either way the program is stopped immediately.
  • Data/calculation errors - these are worse. They are not easy to spot and they are manifested in the data calculation and/or manipulation - this means that the user can no longer trust results that the program creates. Such errors can be very tricky to spot and might go unnoticed - either indefinitely or at least for a very long time.

Who discovers the errors

There are several people there can discover the errors we make in software - developers, testers and users.

If the developers themselves discover an error they (naturally) try and fix it right away (hopefully this is what will happen most of the time). In this case an error can simply be a short distraction for the developer - something that needs some work not related to the task at hand - and in some cases it’ll lead to a full day or several days detour.

If testers discover an error it will lead to some kind of process halt - there will be some back tracking and the error naturally have to be resolved. Depending on the severity of the specific error the process (ending in release) might continue causing the fix of the error to be pushed to a later release - the error thus becomes a known issue and this knowledge can be used to handle situations where the error is later observed and/or reported by actual users. The push of the error fix might (naturally) also occur if discovered by the developer(s).

If the users discover errors in the software - errors that are not already known - a more detailed process must be started to secure information about the error. This process would at least ensure that the error is properly recorded with as complete information as possible making the development team able to reproduce and diagnose eg. - and ultimately fix the error. The process - regardless if the error is known or not - should most likely contain some means for ensuring the user that everything is going to be “ok”.

Long story short the consequences of discovering an error in software gets greater and greater the further the discovery is from the development/testing process.

Embracing the errors

As software developers we shouldn’t accept errors but we should accept the fact that errors will occur.

The real problem is to get every stakeholder to accept this - and most of all keep calm when errors are discovered.