Its not often that I think my job sucks – badly. But I’ve noticed a strong coincidence between the days when that feeling occurs and the days when I am stuck trying to debug a piece of software I’m working with. I understand its part of what I do and given that its not even two months into my newest job, I hardly have a right to crib about it. I also know that this too shall pass, as they ‘wisely’ say. Still it doesn’t make the pain seem any less. And its real!
BTW, I found that there are actually rules to debugging. I’ve un/sub- consciously done these for years, but for those who might need these, here goes from debuggingrules.com (yes, thats the name of the website
) Sounds like a good set of principles to solve other non-software problems as well.
1- Understand the System
2- Make it Fail
3- Quit Thinking and Look
4- Divide and Conquer
5- Change One Thing at a Time
6- Keep an Audit Trail
7- Check the Plug
8- Get a Fresh View
9- If you didn’t fix it, it ain’t fixed
I agree with most things except the last point which means that if you have not fixed the original bug or if you hacked your way to a solution, the original bug is still not fixed. Go back and fix it.
To be honest, I have rarely seen bugs entirely and completely fixed. Sometimes its due to technical constraints such as a cranky browser that just won’t function the same way as the other ones. At other times, there is a time and/or a budget constraint in getting the fix in place. The closest possible workaround is acceptable then till the browser is updated or if you decide to change your software’s features. In an ideal world, it will be nice to have all bugs all well and cleaned up, but sometimes its not that necessary. It all depends.
Am I ready for project management yet?!