All projects have bugs. Have you ever encountered a bug that seemed impossible at first? Projects with legacy parts sometimes make developers avoid touching those parts of the system for fear of breaking even more stuff and they see those bugs as “impossible” bugs. I came to Njuškalo as a junior developer and have faced such impossible bugs. It was challenging, but I didn’t back down. Here are five points that show how I learned to cope with bugs and turn the impossible into possible:

• Realizing we have a bug
• Finding its cause
• Fixing the bug
• Performing damage control
• Testing the fix

Each step can be a nightmare but if you follow these steps, you can resolve the bug in half the time.

1. Realising we have a bug

The first step is the easiest – the feature is not working as intended and an employee, rather than a user, noticed it. Instead of a human we can implement a monitoring tool to alert us if there is a problem in traffic or an error has occurred. Writing automated tests and QA reviews would go a long way in detecting bugs early before they hit production.

2. Finding the cause

If you are having problems finding the cause of the bug it can indicate that your code base is not following architecture patterns or has a lot of dead or duplicate code. You can get stuck on a part of the code that looks like it would be the right spot, but actually ends up being dead code. Dead or duplicate code can result in a longer detection time. Organizing the project can help you narrow down potential bug locations. Structuring the project into domains and layers will allow you to find your way around the code easily. Having descriptive naming can lead you to your bug. If you can find the class by the name of the feature or something similar, the search time is drastically reduced. The important thing is to ask for help when you are stuck; time is the only resource you can’t get back, your colleague may know a single piece of information that can go a long way in finding the bug.

3. Fixing the bug

The fix is usually straightforward when the bug has been located. The danger, however, is hidden in the spaghetti code. You may be fixing your bug but you may also be unintentionally changing the behavior of your application. Bugs are usually the result of rushing and tight deadlines. Take your time, see what you are changing, and analyze how your fix will affect the rest of the application. Remember to apply the boy scout rule (“Always leave the code you are working on a little bit better than you found it.”) while you are fixing a specific part of the code. It will help maintain the readability and health of your codebase.

4. Performing damage control

As long as your application has a bug, it will not be working as intended, meaning sometimes your data will either be lost, written incorrectly, or in the wrong place. Some of the data may be lost but you should implement fail-safes to minimize data loss and risk. Having a backup database will allow you to recover lost data. Setting up multiple standby databases in different time intervals increases your data safety. As an example, the first standby database, known as a slave, will be an hour behind the master and the second slave a day behind. This gives you plenty of time to react if there is a problem with your data. Except for data loss, sometimes a bug can interrupt or stop a process, which will result in a half-done feature. For example, if a user is trying to send a message to a seller, but there is a bug in the code and the message was sent but never received. It is helpful to know which users were affected by the bug so we can rectify the situation. Creating a logging system will allow us to see which users were affected by the bug and what the scale of impact is.

5. Testing the fix

Testing your fix should be straightforward but sometimes it takes a significant time to write instructions for the QA team. This can be due to many different reasons, and the complexity or scale of those reasons can sometimes frighten or discourage you to cover your feature with a test. Nevertheless, testing is the most important step because it gives you a second chance to catch a mistake you might have overlooked. If you get stuck or are not certain how to test something, you always have colleagues around who you can ask for advice and who can help you find the right way. Take your time.

And lastly, remember that each step is essential and rushing will only result in more bugs. There is a fix for every bug just waiting to be found. If you constantly have bugs in a particular part of your code, consider refactoring it or covering it with tests. Having bugs is a normal part of development and nobody is immune to it so take your time and try to reduce the risk of creating a bug by following some of the guidelines that have been provided. Everyone learns through adversity; catching and fixing bugs is just another opportunity to learn and grow. Happy coding, with as few bugs as possible!