I recently attended an event where a speaker gave the metaphor of the age old customs from the Kamba people. He talked about how the wise among the society would inform the community on the right time for planting. Those who heeded to that advice and planted immediately, even in the face of failed rainfall stood a chance of harvesting.
In the spirit of that little anecdote, bug fixing in software development is just like that. Consider a situation where a team uses an agile development methodology. If a bug is discovered at sprint n then fixing it before sprint n+2 is the best favour that the team can do for themselves; that is within 2 iterations. That number is not based on any scientific method but simply a means of bringing out the importance of doing bug fixing as soon as bugs are discovered.
Someone might ask, in an agile approach isn’t a backlog for the next 2 sprints is already set? But then again that is exactly why we have agile, to facilitate that kind of flexibility. So why exactly does bug fixing need to happen immediately?
There are two main reasons as to why this is so:-
- Cost – The cost of having any form of malfunction in the system means that the system will cost more to run. Take an example of buggy code that uses a lot of memory. In the advent of utility computing then it is clear to see that the organization will pay more to have the bug around for much longer. Persistent bugs can not only hurt the bottom line but also the organization’s reputation which is a threat to its very survival.
The other aspect about cost is the fact that it take longer to fix a bug that has been around for longer. That means more man hours are used and hence more premium paid for that fix.
- Risk is defined as a function of probability and magnitude of something undesirable happening. This is exactly what will become of our bug is they are not fixed as soon as they are discovered. In the case of large enterprise systems which utilize object oriented methodologies, it means that there is a high level of code reuse. Therefore the possibility that someone changed the code related to the bug in question will increase as time shift from now into the future. This will also increase the magnitude of changes that have to be made. This simple arithmetic can always serve as reminder as to why now is better that later.
Below are some reading resources supporting the premise of early bug fixing.
http://www.ministryoftesting.com/2013/06/ten-reasons-why-you-fix-bugs-as-soon-as-you-find-them/
https://airbrake.io/blog/insight/why-early-bug-fixing-best-strategy
And also, not all bugs are worth fixingJ.