Fix Issues Every Day

 

Not many developers are genuinely passionate about the quality of their code. However, the ones that do care about it use many interesting best practices. Today I would like to share one of such best practices.

Issues Are Inevitable

Zips

That is the first fact you as a software developer have to accept. You can not prevent other developers from making mistakes, users from clicking random buttons, and infrastructure from accident glitches.

The very best thing you can do is to prepare for all such issues. You should have a way to report the issue. Reporting tool should allow for prioritizing it, set a description with screenshots or videos, and communicate with the reporter. All good support portals follow this approach.

The next obvious thing is to schedule some time for fixing these issues and fix them. It is the most crucial part here as many companies prefer to postpone bug-fixing until they break everything. The best practice is to fix one small issue every day. You may replace it with scheduling several hours a week or during the iteration for bug-fixing only, and there should be no exceptions from this rule!

How To Address Issues

Rubik's Cube

Let us split issues into three different types.

Technical issues are the easiest to find and fix. The flow is straightforward: get the description, investigate and estimate a proper fix, implement it, and cover the fix with a test to prevent the issue in the future. Optionally, you may show the fix to the customer who reported it or to the team.

Business issues are a bit harder to address. You have to check with the customer what is the actual problem. In many cases, the description may have nothing in common with the source of the issue. Then check alternative solutions, discuss them with the customer, ask him to pick the best one, and finally implement it. Additional discovery or training sessions may be needed to explain the fix and how to use a product after the issue has been fixed.

Management issues may be both easy or hard to work on. Overall scenario to fix such problems is straightforward but unstable. There are just two steps: find the source of the issue and adjust the workflow to eliminate it. The devil is in the details, as finding and fixing may take a lot of effort and resources.

Think Outside The Box

Woman thinks

There are a couple of best practices on how to find the best solution.

The first one is typical but most valuable — keep it simple! The best solution is the simplest one. Try not to overcomplicate or overthink, especially if you are fixing a technical issue. Some issues may indeed require more profound thoughts and changes in the architecture, but these are exceptions.

The next one is also simple to tell but hard to master — think outside the box. No matter what type of issue you have, try to look at it from a different perspective. Sometimes a technical problem may require a business solution and vice versa. If you see that the issue is big or hard to fix using a traditional approach, you can change the approach.

Some customers use issues to report missing features or improvements they want to have. Depending on the situation, such a request may or may not be considered an issue. You can convert it to a ticket or a story and move it to the product backlog if it is not.

Finally, you have to track quality. There are many different approaches: measure customer satisfaction, the ratio of opened / fixes issues, etc. Pick one or two metrics that suit your situation the best and fix the issues to improve them. Remember, that good quality product should solve customer problems and make his life easier.