Handling bugs in your development process: the impossible question

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:

  1. Keep an up-to-date and small list of what can be done. This can be useful if a developer has some spare time or as a first issue for a newbie. In both cases, the issue must be correctly qualified and maybe estimated. It would be unfortunate to spend more time than expected on a non-important bug or to leave the new developer alone coding on a much more complex problem than intended.

  1. You might also consider doing sprints (or sessions if you are not in agile) that contain only bug fixes. This is often tedious and not very rewarding for the team. That's why you shouldn't do them too often. But it brings stability to the product and makes the users happy.

  1. If you don't want to make a task force every few months to fix bugs, you can do the opposite by solving some of them on each sprint. You can give your team a target to achieve. There can be a number of bugs to close, score of story points or a fixed time (e.g. 2 hours per week/ per developer). The team will feel less like they are wasting time, but this requires forming habits and having a clean list of bugs ready to be solved.

  1. Another method would be to ask yourself "why should we fix minor bugs? If it's not so urgent, why not wait until it's become critical enough to be upgraded into one of the other two categories (Blocker or Major)?". Bugs will then be automatically prioritised. This implies that some issues will never be fixed. But is this really so bad?

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


Green blobred blob