6 Factors to Consider when Prioritizing Bug Fixes

There are always bugs to fix, but how do you decide which bugs to fix first. Here are 6 factors you should consider, and then use Ozcode to customize your decision process.
As a software company, you must move fast to meet your customers’ demands for new capabilities and deal with issues that turn up in your products. So, you develop new features, adjust business logic, add management modules, refactor your code, improve performance…the list goes on. The thing is, all these improvements require changes to your code, and the more you change your code, the more bugs you’re going to introduce. Now, I want all you developers out there to open your bug-tracking software. Whether it’s Jira, VSTS, TFS, Azure DevOps, whatever, I’ll bet you find a list of issues that goes on forever. Still, next sprint, you’ll have to fix some of those bugs. The big question is, “Which ones?” In this post, I will highlight six factors to consider when deciding which bugs to fix in the next sprint and will then show how Ozcode Production Debugger can help make that decision.

Factor 1: Business cost

Cost is always critical and often the number 1 factor. Naturally, you want to fix the bugs that are putting a dent in your revenues as quickly as possible. For example, if a bug only manifests on a few orders on an eCommerce site, but they are the biggest orders you get, then it should get high priority.

Factor 2: Reach or Frequency

The second factor to consider is the number of people affected by the bug. If your support team is flooded with tickets from many different customers who encounter the same bug, you’d better jump on that one. Conversely, if only one person reported it, you might save that one for the next COVID-19 lockdown. Another way to look at this is how often the bug is encountered. If it’s several times a day, it goes up the list, but if it was only once, two years ago, like I said, that’s your lockdown project. Note, however, that this one could conflict with the cost factor. You could have a bug that only affects a few customers, but if those are your biggest customers generating 75% of your revenue, then lockdown or not, you’ll want to squash those bugs as quickly as possible.

Factor 3: Process

Another factor to consider is the business processes affected by a bug. A kink in the software that orders your company’s coffee supply is one thing; it’s another if orders on the company eCommerce site get processed and charged but not relayed to the stock room to arrange delivery. I, personally, might flip a coin on that one, but you might not be as much of a coffee junkie as I am.

Factor 4: Alternatives

Depending on whom the bug affects, you might want to consider that there is more than one way to climb a tree. For example, you might circumvent that bug in the office coffee supply software by directing your employees to a mobile app until the coffee is flowing freely again. Your customers, however, may not be so accommodating if the bug is affecting them.

Factor 5: Age

Unlike fine wine, bugs do not age well. The longer a bug exists in your system, the higher the cost of fixing it, for several reasons. For one, more users are going to be affected by a bug the longer it lurks in your system, and some of those users will seek better behaving software elsewhere. Then, as new versions get pushed to production, the bug could be manifested in new and different ways, making it more difficult to perform a root cause analysis. Finally, as new modules get added to your application, they may actually depend on the software with the faulty behavior. Then, when you fix it, you may break those modules.

Factor 6: Reproducibility

Reproducing a bug is usually the first step towards fixing it because, once you can consistently reproduce a bug, it’s much easier to understand it fully and, therefore, to fix it. In any software development organization, developer time is always at a premium. The longer a developer must spend reproducing a bug in order to fix it, the costlier it is to fix that bug. If you have two different bugs that have a similar impact on your business, it makes sense to fix the “easy” one (a.k.a., the one you can reproduce) first. But here’s the catch. You can’t ignore the difficult ones for ever even if they are low impact. As you leave these bugs low on your priority list, eventually, the age factor will come into play and the impact of those bugs will increase and raise their priority. In a way, these six factors are self-adjusting.

These six factors will take you a long way to prioritizing bugs for fixing, and you can even fine-tune this method to some degree by assigning weights to each factor. For example, a bug that doesn’t have a high immediate impact on revenue might get 1 penalty point, while a bug that does might get 10 penalty points. You can even assign different weights to each criterion. For example, the Business Cost factor may carry a multiplier of 5 while the Process factor, a multiplier of 2. By assigning penalty points and multipliers to each factor, you can even go some way to automate prioritizing the bugs. This is one way to do it. The problem is that this way is kind of generic, and every business may have specific criteria with which it prioritizes bugs.

Never have to reproduce a production error - Ozcode

Automating prioritization with contextual data

In a previous post, we showed how Ozcode Production Debugger’s autonomous exception capture removes the reproducibility factor. By capturing the full code execution flow of an error, including calling arguments, local variables, relevant log entries, HTTP and database requests, Ozcode presents all the data a developer needs for a root cause analysis, so there’s no need to reproduce the bug.

With reproducibility off the table, it also means that prioritizing low-impact bugs before they age and become high-impact can now be a valid strategy for your team.

But it gets even better than that. Ozcode’s exception capture includes additional contextual data to help developers debug errors. This includes things like machine name, agent version, and service name so you can understand which business flow was affected, and perhaps even assign the bug to the developer who worked on that business flow.

Ozcode takes contextual data a step further and lets you customize which data is collected so you can include that data when prioritizing bugs for remediation. Let’s consider a few examples.

  1. When a backend handles an HTTP request, you can augment an error with a user ID. This can give you a better indication of a bug’s reach to see exactly how many (and which) users are impacted.
  2. When an ordering API processes requests, you can attach a dollar value to each request and, therefore, know the exact value of failed requests.
  3. Any global enterprise could attach a geo-tag to each application running on its servers worldwide to identify any location-specific problems in the company’s network. Errors detected around the company’s corporate site or its top revenue site would get priority over errors in remote, low-traffic location.

By enabling you to assign rich contextual data to each error in your system, Ozcode Production Debugger provides a way to automate prioritization based on the business cost, frequency, reach, and process factors. This kind of flexibility gives organizations the ability to customize their bug prioritization criteria as a mix of both generic factors and other factors specific to the business. The more context you have around an error, the better you can prioritize it and the faster you can resolve it. By collecting rich contextual data with Ozcode Production Debugger, you can prioritize issues based on real-time metrics that are linked to each line of your code. Stay  tuned for a follow-up post about Ozcode’s Nuget API for Contextual Data that specifies how you can customize the data attached to each exception capture in your system. That’s not only data-driven debugging; it’s specific business data-driven debugging.

Ozcode Production Debugger

Automonous exception capture
Don’t chase after exceptions. They automatically appear in your dashboard.

Code-level observability
Get insights into your code down to the deepest levels.

Perfect bug reports
All the data you need is automatically assembled into a single shareable link.

Ozcode Production Debugger - START FOR FREE

Idan Shatz

Comments

Keep your code in good shape!

Subscribe to our blog and follow the latest news in the .NET debugging industry

Ready to Dive into Your Prod Code?

Easy debugging with full time-travel data

The Exception

A Quarterly Roundup

Subscribe to our quarterly newsletter and hear all about what’s happening around debugging with Ozcode

Share on facebook
Share on twitter

Recent Posts

Follow Us

Join Ozcode YouTube Channel

Let’s start debugging, it’s free!

Ozcode Logo

This website uses cookies to ensure you get the best experience on our website.