No need to squish
When writing code beyond your typical Todo List app, bugs are all part of the game. If you’re working as a dev in a larger software company, chances are that your code has been washed, rinsed and hung out to dry by testers and QA before going into production. If you’re working at an smaller agency like me, your deadlines and time boxes might feel uncomfortably snug forcing you to occasionally ship a web app or site that is not as bug free as you’d like.
Apart from popular beliefs,
bugs are not always a result of sloppy coding.
Writing code is a complex thing and introducing third party API’s, plugins and web services that you’re not completely in control of are all variables that can introduce bugs and exceptions. I say that you can’t fix them all and neither are you supposed to. Here’s why.
Bugdet and ROI
Most of us work within some sort of budget, and a tight one at that. Bug fixing eats out of the budget. Of course you need to fix most bugs, but resources spent fixing a bug needs to stand in propotion to what you gain for fixing said bug. It’s a simple Return On Investment. Fixing a bug affecting a 2% non-conversion group of users rather than evolving the application for the mass 98% does not a good investment make. More on statistics and convertions later.
Sadly, there are only 24 hours to a day. Do you and your team want to spend time making cool new stuff or chasing bugs that one guy in the mountains of Peru reported two months ago and that nobody has managed to reproduce since? Keep innovating for the masses, rather than catering to a small group that’s not even your target audience.
Categorize, volumize and prioritize
Categorize bugs into groups of severity, making them easier to handle later on. I prefer my 3 levels of severity: major (show stoppers), normal (should be addressed) and minor (addressed only if time or budget allows.). Whatever floats your boat.
Asserting volume, that is checking to see if more people have reported the same bug, will help you set a priority later on. Keep in mind that most users either find a way around a particular bug or quit the app altogether. So when that one person actually take her time to report a bug, that single report might in reality represent a group of users being affected by the same bug!
Finally prioritize to see which bugs to fix and in what order. Web site stats will be a crucial guide to prioritizing. Does your bug affect a specific browser who’s users tend to yield high conversions? Then that bug is a pri 1! Does your bug affect IE8 users only, who in your case happen to convert low or not at all? Then consider downgrading to a “will not be fixed” status. Google Analytics have great tools for mapping goals, funnelling and ultimately tracking conversions based on demography, browsers and more!
To reproduce or not to reproduce
Once in a blue moon I find the source of a reported bug, fix it and get a confirmation from the reporting user without actually having reproduced the issue myself. Most of the time though, I need to be able to reproduce the bug on my own testing devices in order to actually fix it. If I can’t reproduce it and the user can’t provide an explanatory screenshot the bug won’t get fixed unless there’s a torrent of related reports coming my way.
Pick your battles and draw a line
Bugs are sneaky little critters, and unless you have a clear strategy, you will suddenly find yourself e-mail supporting that guy in the mountains of Peru after all. Having a bug handling strategy that clearly outlines which bugs to handle and where to draw the line will help you bounce bug reports that would otherwise end up being a huge resource hog with very little ROI.
There’s always that one person...
There’s always that one person who hate your UI design, there’s always that one person who will think your UxD suck and there’s always that one person who steals your lunch sandwich. Likewise there’s always that one person who can’t download the PDF from your site, and then it turns out that he has some weird security-ad-blocking-plugin-thingy that hasn’t been updated for 3 years and by the way he’s using IE7. And you just spend 5 hours in support dialogue to figure that one out. Thank you very much. These are the kinds of cases you need to decide on whether to ignore or to actually pursue.
If you’re still not convinced and think that every bug needs dealing with, let me remind you that Microsoft, Google, Apple and most other software vendors ship their products with hundreds if not thousands of known bugs and issues. They prioritize, draw the line and by doing so decide which bugs to address before launch and which to let through the screen door to production so to speak. Without this strategy, their software would potentially never ship at all.
We are none of us perfect, we all make mistakes, and bug fixing is a natural part of every software development process. The trick is to focus on the bugs that matter and ignore the ones that don’t.