Sunday, October 26, 2008

Bug fixing assignment - the greatest dilema of them all

closing to the end of the first version development, the team find few bugs in the version. It always happen. When should these bugs be fixed?
Don`t listen to the engineer which will tell you: "I`m your best engineer , developing the cutting edge features the fastest in the company. Let the new programmers to solve the bugs. This way they will learn the system and make me available to new development".
Does the enginner sounds reasnible to you? A lot of managers falls to this pit. Its not that the engineer is evil , s/he usually really believes that is the best way to work.
It is not.



I got two simple principles for you regaring bug-fixing:
  1. The bug-fixer should be the original coder if possible (and it is the manager job to make it possible)
  2. The bug-fixing time should be close to the finding of the bug time . It does not have to be in that day , but shortly after. (and not in the next bug-fix stage which is 3 months later)


There is a great debate on these two principles, lots of manager will say the complete opposite. I will explain why I believe they are true.

Principle 1 - The bug-fixer should be the original coder (if possible)
  1. feedback - The coder understand his own coding mistakes and becomes a better coder, which produces less bugs.
  2. It will take the orginal coder a slight percentage of the time it will take to another programmer to solve it.
  3. When solving a bug , there is always a small chance to introduce a new different one. When the fixer is not the original coder , the chances become much bigger.
  4. Not all the bugs , but the nasty ones , are only simptoms to other ("chronic") bugs. The original coder will find the real bug and treat it. Other programmer will probably cure the symtoms , not the problem. One simple example: a race-condition bug can be solved locally , but can be a symptom of multi-threading problem across-the-system.
Principle 2 - The bug-fixing time should be close to the finding of the bug time
If you wait to end of the current version to fix the bug you can have few problems:
  1. When all the bug-fixes are concentrated in the end of the version , it is guranteed , that the bug assignment will never be as good.
  2. unstable development version until that time. Finding workaround for multiple developers will usually waste more time that fixing it on the first place.
  3. unstable test version - the QA team may not be able to test a feature well , or waste time in discovering an already known bug. This will further reduce the quality of the version.

No comments: