Dealing with a different type of backlog…your bug backlog

Dealing with a different type of backlog…your bug backlog

on Feb 3, 11 • by Todd Landry • with 2 Comments

As a product manager, the only backlog I typically care about is my product backlog. Do I have the right stories in there? Do the stories have enough detail? Are they properly prioritized? You know, that kind of stuff. Today, however, I’m going to write about a very different backlog, that is the static...

Home » Nasty Bugs » Dealing with a different type of backlog…your bug backlog

As a product manager, the only backlog I typically care about is my product backlog. Do I have the right stories in there? Do the stories have enough detail? Are they properly prioritized? You know, that kind of stuff. Today, however, I’m going to write about a very different backlog, that is the static analysis defect backlog.

A static analysis backlog is created when you run a static analysis product on your code base for the very first time. Chances are pretty good that the first analysis is going to list a large number of defects, some that are without question real, and some that perhaps are not. Do not freak out! This is the first time that analysis engine has ‘laid eyes’ upon your code and it is going to flex its muscles and show you any weaknesses it believes exist. So how does one deal with this? Here are a few strategies to help you:

1) Don’t boil the ocean. Before you even run that first analysis, don’t have a “wouldn’t it be cool” moment, where you decide to turn on every single rule the analysis engine has. There is a reason why static analysis tools haven’t turned on everything.  They are showing the most accurate and critical issues first.  So unless you have unlimited time and resources, your best bet is to start with a core set of rules and run the analysis based on that set. This core set of rules should include things such as memory/resource leaks, buffer overruns, null pointer dereferences, uninitialized variables, and so on. Add other rules once you have this core set under control.

Is your issue backlog making you cross eyed? Try these coping strategies.


2) Baseline your defects. Consider that first analysis your baseline and choose to ‘park’ them for the time being. Chances are the product that the analysis was run on is one that has already been released to the public, and in good working order. Zero out these defects for now, and start to triage them, which leads into strategy #3.

3) This is going to sound pretty obvious, but when it comes to managing your issue backlog start looking at the most critical issues first. These are the ones that are most likely to cause a failure of some sort, so determine if these issues are real, and if so, fix them immediately. Once you’re done with the most critical issues, move to the next level of severity, and continue on that way.

4) Finally, tune your analysis. Any good vendor will allow you to tune your analysis. The benefits of tuning are twofold; 1) you can find code issues that would otherwise go undetected and, 2) reduce the number of issues that the engine reports incorrectly in the context of your source code. You should think of ways to give the tool more context about your code base to increase accuracy.

If you follow these suggestions, you’ll definitely have a better grasp of your bug backlog, and you’ll be able to execute on reducing that backlog quickly and efficiently. If you don’t, then at some point, you may feel a little like the critter pictured here.

If there are any other strategies you’ve tried to deal with your bug backlog, leave a comment or two. I’d love to hear about them.

Related Posts

2 Responses to Dealing with a different type of backlog…your bug backlog

  1. Andrew says:

    Another couple of strategies I’ve heard to reduce the backlog:

    1) a couple of customers we’ve worked with with take a more opportunistic approach. Whenever the developers fix a defect in new code that they’ve introduced, they should query for other (older) bugs in the same file and fix those too. While it’s not a complete strategy to get the backlog down, it’s a “lower cost” way of whittling down the backlog.

    2) a more active and managed way of reducing the backlog. They may set up code review processes or MBO’s to actively move the backlog down (i.e. have an MBO for each developer to reduce their personal backlog by 10% each month). Of course this necessitates defining owners for each defect which can often be conveniently done by components or who last touched the file. Other companies hold dedicated sprints to reduce the backlog, or even schedule “bug fest” days where every developer for a few days just focuses on the backlog powered by coke and pizza.

    3) still other teams move the backlog to a maintenance team. This may be their own offshore team that they use already or use an outsourced consulting team to identify and fix problems from the backlog. In some models, the team may be prioritizing the defects so that the developers can focus just on the most important stuff.

    These are more strategies but these are some of the more popular ones we’ve seen.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top