The reverse correlation between size of change and length of investigation

time to read 2 min | 232 words

imageSomething that I have noticed is that there is a strong reverse correlation between how long it takes to resolve a problem and the size of the change.  In other words, the more time you spend on investigating an issue, the less code will be required to fix the issue.

Case in point, we just closed an issue that took one of the best guys in the team almost a month of investigation to fix. The size of the change? 3 lines of code. My personal best is a 15 man weeks over 3 weeks period with 5 people head done trying to resolve a problem that ended up being a missing ToList() call.

This is usually when there are race conditions, hardware or very long test cycles involved. In this case, this was a problem that could only be reproduced on ARM devices with slow I/O and a particular race condition after we created a very big database.

Thinking about this, it make sense. The more time the investigation takes, the more things you rule out, so eventually it ends up with something subtle that doesn’t work. It make sense, but it can be frustrating for the developer, “I spent all this time, and that is the result?”.

What is your best bug story?