Free From Fear of Fixing Bugs

Ideally, in the world of programming, an application created by an engineer (even in a team) is free from errors or what we call bugs. Almost all applications made in this world must have the slightest bugs. As people have said,

zero bugs in the application are a myth.

Bugs fixing is a mandatory job when it comes to application maintenance. Fixing these bugs also actually takes additional time and costs. Why is this so? Well, the main factor is indeed human error. It is possible to have a lack of accuracy and focus on making the application.

Learning from the dearest case

Let’s take an example of bugs, which can be said to be the most expensive bugs during the application being made. One of them is the case of the launch of NASA’s spacecraft, Marine 1, which was valued at $ 18 million at the time. This spacecraft was launched in 1962, with the USA’s aim as the first country to send spacecraft to Venus. This bug causes the rocket to go out of the way of its proper orbit so that after just 290 seconds of launch, it must detonate the plane. One of the causes for this failure was missing dashes in coded computer instructions in the data editing program, resulting in an incorrect guidance signal sent to the spacecraft.

One example of the most expensive bugs above is why all engineers are more careful in creating applications. There is no need to be afraid if you accept bugs or you make bugs. You better admit it and fix it immediately so that it does not happen again and becomes a problem in the future. As a Software Engineer at the biggest B2B Marketplace in Indonesia, namely Ralali.com, I’m embracing myself to do bug fixing while developing an app, I am working on it. Initially, I was afraid if these bugs could not be resolved or add new bugs. But having the right allies at Ralali.com makes it easier for me to solve these bugs precisely and efficiently quickly.

Seize the moment

I’m opening up to the possibility that bugs are not the enemy. Hence, it challenges me to bear with every case that happens in the development process. I will share with you a few tips when we receive or find bugs and find solutions to fix these bugs.

Step 0: Don’t Panic!

Try to remain calm, patient, and helpful when receiving or finding bugs, even though it happens on Fridays or holidays.

Step 1: Identify and understand bugs

You also have to understand and know the bugs you will fix later with what products are being used by application users. For example, you get bugs when you fail to login using Google, but you don’t understand how to login using Google works. Seek time, try to understand the product to be repaired, and if necessary, ask other people if you do not find it. Remember, this step’s primary purpose is to identify the bugs and find a way out, not blame whoever created the code.

If you have searched and found the answer that these are not bugs, you should not go to the next step (unless you still want to know my tips)

Step 2: Find the problem boundaries from bugs

You can find the problem’s limitations in various ways, such as reading the application log or only getting other information from application users. In this case, the goal is that you will find the exact part of the feature that is problematic.

For example, Ralali.com has several resources to make it easier for every stakeholder to know the results of the released application. As a log report, we use various monitoring tools for both errors and info for each released application. In this tool, all log information from log info, warning logs, and error logs can be known in real-time by all parties. By reading the records, we can quickly find out which parts of the application are problematic.

Step 3: Fix bugs

At this stage, behave and prepare to solve bugs. Close all gaps in the application and make sure it is according to the team’s flow. Good luck to you!

Step 4: Test your fix before release

Remember this test is not only done by a Quality Engineer but also by yourself as a Software Engineer. Create unit tests, regression tests, and other tests for every bug fix you make. Think of every test case that occurred when carrying out this fix. Re-validate whether every code you create has fixed these bugs or caused new problems elsewhere. Both you, Quality Engineer, and the stakeholders involved must focus and make sure all testing needs to be done at this stage to minimize recurring bugs.

Step 5: Think about the future

After these fix tests are done, remember to think about the future of your code! Recall whether your fix affected anything else or it will cause new bugs in the future. You need to record this in a document so that the bug-fixing features you make are known to all stakeholders.

After you have done all these steps, you can release bug fixes, but you still have to monitor the bug fixes you do. Use various dashboards that make it easy for you to monitor every movement of the applications you have appropriately released. It would be best if you also tried to implement “zero known bugs” so that any work you do later will not cause problems in the future. If you can, do it in your team to have the same policy. Maybe a few tips from me will help you not to be afraid to fix bugs.

Bugs are indeed zero priority and solve it as efficiently as possible.