If you watch people working you can tell the level of quality they are likely to produce. This does not only apply when they are working on new code but also defect resolution.
A good analysis of the problem is the basis for a working solution. If you do not understand your problem it is not time to fix it.
Reproduction of a defect is hard sometimes, especially when other systems are involved or when it is a multithreading issue.
Change the implementation so that it fails at the point you want it to fail. For example, you are running into an assertion because you have forgotten to define a configuration value. In this step, you change the component startup code to check for the existence of the configuration value and throw an exception if it is missing.
Verify it Fails
Now you verify that it is really failing at the point you expected. Run the same reproduction again as in step 2. Now the behavior should be different and you should see the errors you expect.
In this step you will do the actual resolution of the defect. Because you have a good understanding of the problem at this point, a way to quickly reproduce and a good error handling, this might be the easiest part.
In this step you run the reproduction step 2 again to see if the defect really went away.
Some things to remember:
- If you find yourself looking for workarounds, this usually means you failed to suffiently analyse the problem
- Don't give up. Every step above can be performed on any problem. It is just a matter of effort. If you give up, you will definately spend more time.
- There is no such thing as the economy of bugs. At the end, it is always cheaper to resolve a defect than it is to somehow workaround it.
Spend the following amount of time:
- Analyze - 40%
- Reproduce - 10%
- Fail Fast - 10%
- Verify it Fails - 10%
- Resolve it - 20%
- Verify Resolution - 10%