Improving productivity to 1 Bug correction per man/day

Question

I am a senior software engineer, and a few months ago I have been asked to help with co-ordination of bug corrections. The project manager (non technical) has given me an objective of improving productivity to 1 bug correction per man/day. This has been a real challenge, and I would like to know what other developers/managers may have done to improve bug correction rates.

Some factors that play a role in this situation:

• team is geographically distributed (Europe, Asia, Australia), 10-20 developers in each area
• large code base that I am not all that familiar with as I have been with the company for only 9 months
• only the least experienced developers are allocated to bug corrections, most capable developers are working on enhancements
• we follow agile, so we use source control, continuous integration, bug database, project has schedule and specs for new work, we have testers and do usability testing
• our code is dependent on many in house and third party components / libraries
• program manager has some old bug correction metrics, showing 0.7 bug correction per man/day. My concern is that this was based on a team of experienced developers working on a prototype, correcting bugs in code that they themselves wrote. Now I am co-ordinating a team of developers that are not familiar with the code, and the bugs are originating from the validation team.

Some more information after reading first few answers:

• I have tried to argue against using the bugs corrected productivity metric, didn't get too far with this approach
• all bugs are prioritized (1-5), include a severity (1-5) and tagged with additional information (eg. BLOCKED by another bug, CRASH, NOT-REPRODUCIBLE, etc)
• most bugs have a unit test case written when they are corrected
• bugs in particular area of code are allocated to the people familiar with that area, if possible
• bug correction rates are tracked on a per team basis, and correction history is kept
• in daily stand ups I try to get people moving by asking for blocking issues and solving them
• all new code is written with unit tests
• yes, i have been doing my best to improve the productivity metric by various means - closing old non-relevant bugs, creating and correcting bugs for issues that would otherwise be solved without a bug report

• i have developed python scripts that access the bug database directly to automate some mundane aspects of bug management and for report creation

-

Answer 1

While bug correction rates are a valid metric in some circumstances, they can be misguiding in others. Some bugs are obviously a lot more difficult to fix than others.

Ideas you may want to try include sorting your bugs into different categories. Base the sorting on metrics such as difficulty to fix, importance to the customer, or complexity.

In an agile environment you are mostly focused on writing test code. Think about he life cycle of a bug. One of the first things you try to do is reproduce it. You can measure how far along you are to fixing a bug if you can write a test case against it. Doing just this will improve bug correction rates.

Answer 2

I think a good starting point is to systemise the bug fix process. If you're going at <1 bug/day I'm assuming your code base is large, and these bugs are difficult to find/reproduce. I'd start with some analysis

1) How long to understand the bug

2) How long to find/reproduce

3) Which code is being fixed (is there a pattern here)

4) when you fix, do you add another unit test

5) Do you review individual and team where bugs are happening

A couple of weeks doing that will give you a really good basis for future direction. It will also be a professional approach that your manager should buy into.

Answer 3

It would be helpful to switch off between experienced developers fixing bugs and junior developers creating enhancements, but this doesn't sound possible with your situation.

Try to not let people get stuck. If someone has an issue and is getting nowhere, encourage them to get help and get on the right track.

As per the above poster, make the experienced developers write test cases for their enhancements. (Of course, this makes the bug fixing harder)

You could always intentionally add bugs and fix them.

Answer 4

You could ask the developers what is their opinion is the most time consuming part of the bug-fixing cycle and think how you can use this information.

They are doing actual work and it's reasonable that they have the most information on what the bottlenecks are.