Handling bugs in your development process: the impossible question — Blog — Ponicode

Aljosha, software engineer at Ponicode, shares a few tips on how to handle bugs and implement healthy processes to take your software to the next level.

Before we start, let’s ask ourselves a simple question: What is a bug? There is no unique definition, but for the Ponicode team, we made it simple. A bug is a malfunctioning behaviour observed in production. This means that it can be a button with the wrong color, a broken functionality or even the impossibility to connect to the platform. Any unwanted behaviour is a bug. We’re excluding from this definition the problems found in pre-production instances, as they do not impact our users.

Here, we’re not going to talk about how to avoid bugs, but how to manage them once in production. Despite all the efforts that can be put into ensuring the quality of the code, the tests and the quality assurance, some small (or big) bugs always end up in production. So you have to know how to deal with them in a fast and efficient way. This article is by no means a universal solution to this problem. It’s simply a set of ideas to help you find the best method that fits your product and your team.

Identify and log bugs

In order to fix a bug, we must firstly identify it. This may seem obvious to you, but it is essential for a good bug process. To be as efficient as possible, you need to have a unique list that gathers the different sources of feedback (user messages, tests report, found during development or demos…). This database can be whatever you want, a Jira project, a Trello board, an Excel file or even post-its on a wall. I won’t recommend the last one for practicality reasons but it can be a nice decorative touch.

Sorting and filtering

Once you have a good collection system, you need to sort through all the information gathered. This exercise is composed of 3 actions: sort, qualify and prioritise.

Sorting: It’s common for a bug to be listed twice (or more). The larger the database, the more frequent the duplication will be. Especially if the bug tracker is managed by several people at the same time, or worse again if it’s a public one.

Qualify: Qualification is the longest step. This required checking that the explanation and the method of reproducibility are clear, that the bug is indeed a bug and it can be easily reproduced. You can even consider writing down possible solutions if you already have some information about it. This may help to estimate the time required to fix the bug.

Prioritise: Once you’ve identified the problem, how to reproduce it and maybe even how to fix it, you must then determine its priority. Or rather, what is the deadline to solve the problem. This is essential because if you don’t give a criticality to issues, everything is urgent and therefore nothing is urgent. At Ponicode, we basically use 3 levels of priority:

• Block: A regression in production that needs to be fixed right away because it prevents the application from working properly (e.g. impossible to connect to the application…). In this case, one (or more) people from the team are dedicated to the problem until it’s resolved.
• Major: A regression or behaviour that complicates the user’s experience without preventing the use (e.g. a non-essential feature is broken). In this case, the bugfix must be prioritised in a few days or weeks regarding other tasks priority.
• Minor: Everything else.

The first two categories (Blocker and Major) are easy to prioritise but what about the third one? How do we keep these ‘minor’ issues from falling into oblivion? That is the (impossible) question. Since it’s not really urgent, something else will always be more important to do first.

The endless well of bugs

As I said earlier, we don’t have a reliable answer, but here are a few things to explore:

If you have other methods for managing your bugs, feel free to share it with us on our Slack.

‍

Originally published at https://www.ponicode.com.