Bugs are an unavoidable reality in our journey of development. But the problem arises when we ignore them and let them grow to become monstrous hurdles in our path of development.
- It is Friday evening and John wants to deploy a week’s worth of work. But his code is crashing again and again and he feels miserable because of the approaching deadline and knows he might not make it.
- For the last three weeks, Anna is telling her manager that she will fix that small problem today but at the end of the whole day of debugging, she is still clueless about what is going wrong.
- Alan has a fear of developing anything new. Whenever she releases anything new entire system starts to crash down.
If you have been in a similar situation, there is a very high chance that you or someone else from your team left the small bugs in the code and now they are hidden, powerful, and lethal. Let’s try to understand how they grow.
How fast do they grow?
They grow exponentially. If a bug will take 15 min to fix immediately after its birth it may take an hour to fix after a couple of days. A few weeks pass by, and now this is a problem of the days. Wait for a year if you want to spend some solid months on it.
Who Feeds them?
To figure out how they grow so fast, we need to understand what they need in order to grow.
- Loss of Context: When we are working on a problem we have a very fresh understanding of that problem. But as time passes and we move to new problems we start to lose the context of previous problems. It becomes difficult for us to what could have been causing that problem.
- New code may bury the bugs beneath the layers: As we add more and more features bugs start to get buried underneath the layers allowing them to easily conceal themselves.
- Bugs have naughty cousins: It is common wisdom, If you found a bug, do more testing there will be more sitting there. Usually, when we have more than one bug at the same place they are much harder to find and multiple occurrences are common more often than not.
How to deal with them?
Let’s use the wisdom of ancient automakers to tackle this modern problem.
Fix them ASAP.
… companies such as Toyota, Honda, and Nissan spent an average of 16.8 hours making a luxury car. Parts went in at one end of the factory, and, about 17 hours later, a Lexus emerged. And they had 34 defects per hundred vehicles. Not bad. In Europe, though, the story was different. Such companies as Mercedes-Benz, Audi, and BMW took 57 hours to make a car, and they had 78.7 defects for every hundred vehicles.
… In a Toyota plant when a problem shows up on the line, every worker has the ability to stop the whole line.
When that happens, everyone swarms around where the line stopped — not to yell at the guy for stopping the line, but to fix whatever problem is there. They don’t want any cars coming out the other end with things that have to be fixed. They fix the problem once, and it’s solved forever.
If they don’t, that same defect could go into hundreds of vehicles.
— Scrum: Doing Twice the work in half the time
That automaker knew that.
- The testing is not the end of the process it is the beginning of new fixes.
- If we will wait for the things to complete for testing it is already too late.
- If we will prioritize the quality we will improve production. (you fix bugs early)
- Let’s fix the fault before showing output. Don’t ignore them. (Don’t leave the bugs in the code just to show that you are meeting the deadline unless it has a huge stake at risk)
- Those who are making it can test it better. (Testing is the job of the software developer, QA’s job is to ensure that developers are doing their job right).
If you liked our approach let us know and you can follow CYBR Notes to see notes like this from our team.