Published: 25 May 2021 9:54 am  Author: Pedro Loureiro

Bugs Within The Software Development Life Cycle – How Best To Manage?

Regardless of the competency of an engineering team, bugs are part and parcel of the life cycle of every software development project. Within the software development paradigm there are best practices for nearly every part of the development life cycle except bug management. We have participated and witnessed several different approaches over time but there doesn’t seem to be much around best practices.

Common Scenario

1. A bug is reported either directly(customer support, internal employee, client etc) or via an automated notification management tool, at Kudocs we currently use Rollbar.
2. One or more members of the engineering team immediately starts assessing the bug. There could be several reasons for this, a few possibilities are below:
   • They are generally curious and want to identify/fix something impacting the business.
   • They want find out who likely introduced the bug incase it was them.
   • They are not engrossed in their current work and looking for distractions.
3. One or more team members join a call/discussion to talk through the bug which may turn into a pair/multiple programming session. Investigating the issue in real time and applying code fixes once the problem is identified.
4. The bug is now fixed and a message put into the slack saying something like “This bug is now fixed, nothing to worry about” OR more time is needed to solve the issue and the people involved in the call/discussion are now responsible for this item
5. Everyone returns back to work once the problem is solved.

The above may seem like a successful outcome however there are a number of problems.

• One or more of the engineering team was distracted from doing their current work, this may have been deep work requiring maximum focus without interruptions.
• There is no real evidence about what the bug was, why it happened and how it was resolved apart from the team member(s) who participated. There is a bug in Rollbar, a slack message and a git commit but nothing collated.
• The team member(s) who picked up the initial bug may not best placed to resolve. It can often be the case that the person who picks up the bug first is then required to resolve it by default, finders/keepers.

The Solution – Bug Rota

1. One team member is responsible for picking up bugs on any given day.
2. The first priority is to log the bug in a work item which contains all the relevant data. Various tools for this, Rollbar, GitHub or some other project management software.
3. The team member conducts an initial investigation to identify the impact of the bug, again capturing any relevant information on the work item.
4. Once identified the team member then assigns a priority to the work item and escalates to the relevant team member. They may assign it to themselves.
5. The team member responsible will see they have a new bug work item in their queue and depending on the priority/status can decide if it needs immediate attention or can wait for later.
6. Other team members not currently involved can digest the work item in their own time either offering support/assistance if relevant or choosing to ignore if its not something that needs their attention. They at least have some context of the bug and what the status its at.
7. Product owners/managers can also digest the work item and may need more involvement if its a direct business/customer concern.
8. Once the work item is eventually resolved you now have a work item covering all the various components and its life cycle as part of the escalation process. The work item, Rollbar bug and relevant git commits can all now be synced. This will help if the bug happens again or if it has introduced another bug as a result of any changes.
9. The team now know they have a process in place to deal with bugs. The person on the bug rota also has the comfort of knowing they don’t necessarily have the responsibility of resolving any particular bug. They need to capture the bug, do an assessment and escalate. Very easily passed on once all the necessary information is captured.

Summary

There are many different paths a bug can take depending on its impact to the business but the main concern from an engineering point of view is protecting the engineering team so they have the necessary uninterrupted time to be as productive as possible. Having a dedicated resource on a bug rota puts the other team members minds at ease knowing they can fully concentrate on the task in hand and know that bugs are being addressed. They can then choose the best time to digest the context of any bug and wether its something they need to be involved in or something they need to be aware of for future reference. The work item contains the full life cycle so easy to map all the relevant steps that were taken. In future posts we will cover the process of tools/techniques that help to troubleshoot a bug.