Bugs are annoying. They tend to slow down your development and ignoring them costs a lot of your teams' time. This is how we deal with them.
Bug-fixing is one of the most important activities of a development team. Over the years we polished our process and I am happy to share insights on how we do it at Devana in the example of our ManageWP product.
When a bug is born
Bugs are reported by users or by members of our team, most notably Customer Happiness team.
We then confirm these and only when there is a way to reproduce it, the bug starts its vivid and hopefully short life within our Trello management system. We refer to bugs as ‘user frustrations’.
Apart from real emergencies (site doesn’t work) we fix bugs on Mondays and only on Mondays. Other days of the week are reserved for new development.
We usually first spend an hour to do estimates. This helps us sort the bug list so that we achieve optimum efficiency.
Every bug is defined by:
A – Affected users (1 – 10, 1 being single user 10 being all)
B – Importance/frustration for those affected (1 – 10, 1 being a tiny visual glitch, 10 being product does not work for them)
C – Estimated time to fix the bug (1 – 10, we use increments of 15 minutes so 1 is 15 minutes and 10 is 150 minutes)
Bug score = A * B / C
This gives the score in the range of 0.1 – 100.
As you see we have three different factors that we believe are important in describing the nature of the bug. Sometimes there is a frustration that is not really big but is quick to fix and so it will get a high score.
To make this process more efficient we have developed a Chrome extension. We made it public and you can download it here – Devana Trello Estimate.
We always fix bugs in pairs. Two developers use one computer and one keyboard and work together on fixing bugs. We change pairs every week.
We found out that this is an extremely effective system that works really well for bug-fixing. The main advantages are:
- Two people can brainstorm and debug issues much faster
- At least two people have seen and confirmed the commit. This significantly reduces new bugs and increases overall code quality.
- We prevent ‘towers of knowledge’. A tower of knowledge is the (only) developer that knows everything about the system. When people work in pairs, the knowledge about the system gets spread evenly across all members of the team, effectively making everybody capable of working on anything.
The idea for pair programming came from Menlo Innovations.
Q: What if the bug does not get fixed this Monday?
We postpone it for next Monday.
If it is a particular user problem, it will get x2 importance next week (age factor). If it still does not get fixed it will get x4 until it swims on the top of the list.
Also in case of ManageWP, we give the user a free month of subscription to compensate them for the wait.
Q: How many bugs can you fix in a day?
One pair usually fixes 8-10 bugs in a day.
Q: Why Mondays?
We usually deploy the fixes same day or tomorrow. So we have the rest of the week to fix anything we might have broken (which happens rather rarely thanks to pair programming).
Photo by James Nash (aka Cirrus)
Photo by VFS Digital Design