In the web development industry the word ‘bug’ has become a misunderstood and often misused word by clients and is thrown about like rotten tomatoes at the Tomatina festival (but without the fun).
To clear up this irksome issue we try and educate our clients by defining issues into 3 categories of errors, new features, or bugs. Let’s start with the easiest one to identify and progress to the ambiguous.
In this context a new feature or change request is (usually) something the client thinks should have been programmed but they haven’t actually requested it before in their original brief/technical specification.
An error is something that has been coded incorrectly for whatever reason. Programming errors can then be split into Compiler, Run Time and Logic errors.
Microsoft explains them as;
- Compilation errors; most compiler errors are caused by mistakes that you make when typing code. For example, you might misspell a keyword, leave out some necessary punctuation, or try to use an End If statement without first using an If statement.
- Run time errors; typically occur when your program attempts an operation that is impossible to carry out i.e. division by zero. If you had the following statement: Speed = Miles / Hours and if a value of 0 is entered for Hours the division operation fails and causes a run-time error. Logic errors are the hardest to find and fix
- Logic errors; are errors that prevent your program from doing what you intended it to do. Your code may compile and run without error, but the result of an operation may produce a result that you did not expect.
A bug is a coding defect that produces an incorrect or unexpected behaviour or result. In his brilliant blog ‘It’s Not A Bug, It’s...’ Dalip Mahal tells us “Code can only be considered a defect if it differs from the specification” and that generally, the problem is that the requirements were never written because many companies/clients do not create sufficiently complete requirements before starting development.”
He goes on to explain that “Incomplete (and inconsistent) requirements and unrealistic deadlines often force developers into making decisions about how to implement features. The end result is that developers are regularly told that they have defects in their code” when actually they are ‘undocumented features’ because the requirements were never written in the first place.
So be careful before you exclaim "What does a developer do?", state something as bug or pass out blame for things not working as you assumed they would. Never assume anything in creating a website - always think properly (not quickly) about the system and write down every requirement you want. Yes, of course you cannot possibly think of everything but that is no reason to blame your programmer. Remember the old teacher saying “never assume as it will make an ass out of u and me”.
Don’t even get started on when you inherit a website/system that someone else has programmed and you find a bug!!!
Animated gif: When fixing a bug in a legacy system....
Blog written by Natalie Wiggins