Software debugging Part 1: 90–10 Rule.
How do you fix a software error quickly?. This will be part of a small series to what I do in my case.
Everyone knows the 80–20 rule. For those who don’t a small definition is that 80% of the problem is due to 20% of bugs. Fix the 20% and your 80% is solved. That’s really a good rule. Hence I am renaming my method to rhyme with it. It’s an old method, you will get it when I explain it.
The 90–10 rule I use is, knowing the error solves 90% of the problem you have at hand and fixing it is only the 10%. Previously experts used to say “know well what the error is before solving it”. It’s true, once you figure out what the error is and understand it, then fixing it is easy. Define the error and why it may have happened as much as possible. Put in some assumptions, it may be right or wrong. Let the ‘wrong’ be ‘right’ for some moment, you can clarify it as you move forward. Having a wrong assumption is always better than having no assumptions. With no assumptions your debugging is just a brute force approach. It may fix or it may not, but it will stress you out. I have tried debugging with and without this approach and what I noticed was that brute force approach really stresses me out. The 90–10 rule would take same time or less than the brute force and won’t stress you out.
So this is my first advice. Know the error before you start debugging it.
How do you know your error?
- Read the error messages provided and understand it. If you understand the exact problem solve it.
- Put in assumptions if you don’t get the exact problem
- Search the error message in google and understand what others have to say about it. If there is a solution use it.
- If no solutions provided then search based on your assumption.
- If nothing happens post the error in stackoverflow.com
If the above step doesn’t solve your error use my next advice