Increase productivity to 1 Error correction per person / day

I am a senior software engineer, and a few months ago I was asked to help coordinate coordination of bug fixes. The project manager (non-technical) gave me the task of increasing productivity to 1 error correction per person / day. This was a real problem, and I would like to know what other developers / managers could do to improve the speed of error correction.

Some factors that play a role in this situation:

  • the team is geographically distributed (Europe, Asia, Australia), 10-20 developers in each area.
  • a large code base that I’m not so familiar with, like with a company in just 9 months.
  • only the least experienced developers have been fixed to fix bugs, most developers are working on improvements
  • we are flexible, therefore we use a control source, continuous integration, a database of errors, the project has a schedule and specifications for new work, we have testers and usability testing.
  • our code depends on many components and libraries of the house and third-party developers.
  • the program manager has some old error correction indicators showing 0.7 error correction per person / day. My concern is that it was based on a team of experienced developers working on a prototype, fixing bugs in the code that they wrote. Now I am coordinating a team of developers who are not familiar with the code, and errors arise from the verification team.

Additional information after reading the first answers:

  • I tried to object to using the corrected performance errors, did not go too far with this approach.
  • all errors take precedence (1-5), include severity (1-5) and are marked with additional information (for example, BLOCKED with another error, CRASH, NOT-REPRODUCIBLE, etc.).
  • most errors have a unit test case, if fixed.
  • errors in a specific area of ​​code are highlighted by people familiar with that area, if possible
  • error correction indicators are tracked based on each team, and the history of corrections is saved
  • in everyday struggles ups I'm trying to get people moving by asking for blocking problems and solving them.
  • all new code written with unit tests
  • yes, I am doing my best to improve the performance indicator in various ways - closing old irrelevant errors, creating and fixing errors for problems that would otherwise have been resolved without reporting an error.
  • I developed python scripts that directly access the error database to automate some of the mundane aspects of error management and reporting

    -
+4
source share
4 answers

I think a good starting point is to systematize the error correction process. If you go to <1 error / day, I assume that your code base is large and these errors are hard to find / reproduce. I would start by analyzing

1) How long to understand the error

2) How long to find / play

3) What code is fixed (is there a template here)

4) when you fix, you add another unit test

5) Do you consider the person and team where errors occur.

In a couple of weeks, this will give you a good foundation for your future destination. It will also be a professional approach that your manager should buy.

+3
source

While error correction factors are a valid metric in some cases, they may erroneously introduce others. Some errors are obviously much more difficult to fix than others.

Ideas you can try include sorting your errors into different categories. Base your sort on metrics such as difficulty to fix, importance to the client, or complexity.

In a flexible environment, you are mainly focused on writing test code. Think about his life cycle error. One of the first things you are trying to do is reproduce it. You can measure how far you will correct the error if you can write a test case. Doing this alone will improve the speed of error correction.

+3
source

It would be useful to disable experienced developers who fix bugs and junior developers who make improvements, but this does not seem possible in your situation.

Try not to let people get stuck. If someone has a problem and is no good, ask them to get help and take the right path.

According to the above poster, so that experienced developers write test cases for their improvements. (Of course, this makes error correction difficult)

You can always intentionally add errors and correct them.

0
source

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

They do the actual work, and it’s reasonable that they have the most information about which bottlenecks.

0
source

All Articles