Dan Fox bio photo

Dan Fox

Software developer interested in learning New Things and applying them in Real Life

You meet many different types of software developers.  Some are unbelievable with UI, some brilliant with business logic.  Some (and these are rare) are even remarkable with regexs!  Some might be great at gathering requirements.  Some can be branded “good” and others “bad”, but these are all relative and dependent entirely on your perspective.  However one thing is common - they will produce bugs.

And what’s one of the most important factors to take into account when estimating how long bug fixing will take?  None of these - it’s familiarity with the code.  Put the world’s greatest developer with the world’s worst codebase and you’re not going to fix a bug.  Familiarity is king in the bug-fixing arena.  Now knowledge sharing is great and should be done as much as possible but it’s simply not possible for two people to have exactly the same knowledge - someone will always know more than the other about a specific topic.

In the past I’ve heard things like “we have 10 bugs which will take two days to fix, if we put two developers on it, it will take 1 day to fix”.  Software development doesn’t work like that.  Particularly with a developer that is very unfamiliar with the code - chances are they are just going to slow down your other developer by asking them random questions while they’re traipsing through their own quagmire of bugs.

So if, as a developer, you’re asked to help someone else fix bugs, let your manager know it may not be beneficial.  Take a step back, and let the main dev get on with their work, and pick off the easy wins.  Do the admin side of the bugs.  If there are ambiguous problems, clarify them.  Do what you can to make the other developer more effective.  Everyone will be better off in the long run.