What Is A Bug
A bug is something in a software release which is not working correctly. This could be a button which breaks when you click it, a dropdown with the wrong items or a screen which you didn’t expect when you did something.
A bug is not a missing feature. It is not something the development team missed out because you didn’t tell them explicitly you wanted it. It is something that does not work as the development team intended.
Why Do Bugs Happen
Bugs happen because the developer has made an incorrect assumption, or they have the wrong information about how dependant systems work.
Bugs happen when we make mistakes in implementation. They are a normal occurrence and anybody can make them. Even this guy…
When a bug is reported to a developer the first thing they try and do is isolate the bug by ‘recreating’ it. The more fussy the developer, the more they will try and create an exact duplication of the problem in their own isolated environment (usually their own machine).
I like fussy developers.
As soon as our fussy developer find the bug in question they get a hit of dopamine. Dopamine is a drug which is released by the brain to reward the human owner for something they did correctly which they have been trying ‘hard’ to do.
The problem with dopamine is that it’s a drug! And like all drugs taking some leads the user to want to take more – or so my lil’ fwen tells me.
In order to get another hit of dopamine the developer needs to fix the bug. Because after fixing the bug the developer can stand up, tell the team they have won the bug competition and do a victory march straight to the
beer coffee machine.
This dopamine reward cycle drives the developers day; it’s a mini cycle of problems and solutions. However; it can easily cause a developer to take too many steps without thinking through the ramifications of those steps…
During our developers dopamine high they have crossed an invisible boundary. This boundary is a critical step which is required if you want to make sure that the one bug you fix hasn’t created another one.
In order to fix a bug a developer must make changes to the code. If we think back to our first dopamine hit the developer has worked out how to ‘recreate’ the bug. This means that they analyse the code and keep running the recreation steps in order to test if the bug exists. They will start to change the code and when they run the recreation step and the bug disappears then they ‘think’ they have completed the work as the bug is now ‘fixed’.
However they may have changed a lot of code during this process. Changing code is no different in terms of outcomes to writing new code. And as we know new code has lots of ‘bugs’ right?
Changing the code base to fix one bug has caused a bug to pop out somewhere else. No-one likes things popping out unexpectedly . The development community call this popping out event an ‘unintended consequence’. I’m happy for you to use either term.
The outlined problem is SOLVABLE. In order to solve it what we have to do is to put some guard rails around all the current code that a new bug ‘could’ come out from. These guard rails will stop any new bugs from appearing. They provide a ‘warning’ to tell us when we have an ‘unintended consequence’.
They come in the form of our most useful tool when developing software it’s called: ‘test automation’.
The process works like this: We wrap all of the current code (which could be affected by the change) in test automation. We do this ‘AFTER’ we have isolated our bug but ‘BEFORE’ we begin changing the code.
As we fix the bug we simply keep running the test automation (warning system) to make sure we haven’t broken anything (unintended consequence), we now have a check to make sure nothing CHANGED.
The other little thing we do is add another test for our new code to check that the new bug fix works also!
This let’s the developer test the bug in confidence and fix the bug knowing that when we fix the bug we don’t create another one!
And that is how you can avoid this story we see over and over in software development… Happy bug hunting!
I am the founder of Logic Room.
I help our clients build robust and flexible software by either doing it for them with my team in Reading or coaching their in-house team to do it.
If you would like to reach out to me please do!