Bug prioritisation – false optimisation ?
|Teams have limited time and resources. There will always* be more things to do than what’s possible. Then how do teams choose what do ? many teams adopt some sort of prioritisation framework and sort the work items based on the priority. This might work for feature requests and system improvements, will this work for bugs ? I am not talking about high impact bugs where large number of customers are impacted or the bug brings down the entire system. These kind of bugs get unconditional love from the team and midnight releases as well. I am talking another class of bugs, where impact is low when seen in isolation. These kind of bugs tend stay in the system for long time and tend to get no attention.
Bug will find its way out
My take is that, bug fixing process should start immediately once it is identified/reported. It doesn’t matter what you are working on, drop it and fix the bug first (irrespective of its impact*). Its easy to get bug priority wrong as we tend see them in isolation. In complex systems, it not easy to determine how the said bug will interact with the other components. Also bugs tend find interesting ways to interact with other bugs and cause major issue.
Even if you wait, customers will not wait
if the bug is not fixed in reasonable amount of time, customer will start building around/on-top of the bug. Once that happens, you can never completely fix the bug. I have seen several instance where a bug need to be explicitly maintained because of the client dependencies on it.
B2B SaaS is very competitive market, customer acquisition is very costly compared to upselling. If customer reports a bug that is impacting their business, I think its teams responsibility to fix it immediately. Fortunately, I never worked on a system where bug fixing is taking much of the teams time, So I don’t know if this approach works for teams that are already spending lot of time in fire fighting and bug fixing (large scale rewrite doesn’t seem to be the answer to this problem).