Often in coding, I find it very slow and difficult to detect the root cause of a bug and sometimes I end up going to wrong point in my code. It's painful. I know that to detect the root cause of a bug is a very important skill for programmers. Does anybody have a trick or technique to suggest a good way of finding the root cause?
-
4There's some good advice in Code Complete 2, in the chapter on debugging (chapter 23). And the rest of the book is well worth reading too :)– MarkJJul 19, 2013 at 10:14
Add a comment
|
3 Answers
Ask why a lot, and keep asking it until the problem is clear.
- Why did the code crash? Because we got a divide by zero.
- Why did we get a divide by zero? Because X was zero.
- Why was X zero? Because it was passed in by function foo.
- Why did foo pass in a zero? Because it was set to the total number of relationships that the object has
- Why did this object have zero relationships? Because that's the default value before the object is fully initialized
- Why was the value not set to be greater than one during initialization? Because there is a set of cascading if statements without a final catch-all else statement.
- Why did this object not satisfy any of the if statements? Because the code assumes that every object has at least one parent, or at least one child.
- Is that a valid assumption?
This technique is often referred to as "5 Whys". You can read more about "5 Whys" on wikipedia.
You might also be interested in reading answers to the question What is your most useful technique for finding (or preventing) bugs?
answered Jul 19, 2013 at 11:09
-
-
4This technique is called 5 Whys and it's incredibly useful. It's a tool for root cause analysis found in many environments striving toward Lean or using Six Sigma, among other process improvement techniques.– Thomas Owens ♦Jul 19, 2013 at 12:23
-
I think your answer is great for the question being asked here. The bigger picture (as provided in this answer to a different question ) could also help in limiting the amount of time spent in finding the root cause of a bug in the code by focusing on defect prevention early.– malteJul 19, 2013 at 13:07
-
@ThomasOwens: thanks for your comment. I've updated my answer to include the link you provided. Jul 19, 2013 at 13:59
Testing a huge project at once will give you a headache. The best way to detect root cause of problem is to test the smallest units individually. When all the smallest units are correct then test bigger units made by 2 of them and so on till you get to the top.
Make a habit of maintaining test cases for all units so that if a new bug appears after you change some part then you don't have to write the whole thing again. You can apply the tests to see what is the problem and exactly where.
Maintaining individual modules separately with their test cases can be save you a lot of problems in the long runs. When you want to make changes make changes in the smallest units, test them and then use them.
That can help you in the long run. Believe me, I didn't have the habit of maintaining testing code alongwith the code and it made my life hell. I am trying to fix it. Don't make the same mistake.
answered Jul 19, 2013 at 10:30
-
1Just to add a bit more to this, read: stackoverflow.com/questions/1544642/…– GibsonJul 19, 2013 at 10:41
Yeah nice question though may sound very abstract or poorly directed. However if it is directed or not, again depends your perspective.
Yess debugging is very very important skill. The best/perfect way to deal with them is to have holistic view to them, strategizing for them - along their life cycle.
I dont want to be theoretical here. To start with we can start with their source.
Bugs are introduces by us - developers, due to
- lack of understanding of technology
- lack of understanding of domain, business workflows
- ignorance
Lack of understanding of domain and ignorance (unintentional - may be due to working under pressure etc.) are easy to deal with. Having solid technical understanding really takes nerves. Yess really. If you dont trust me just start off with JavaScript and try to master it. Its the most quirky/confusing language but still runs the World Wide Web. I am trying to learn it for many months and I believe am not even done with 5% of it yet. Just for an idea about how things may be confusing, you can have a look at how confusing but still interesting the behavior of this keyword is in JavaScript at here.
Apart from understanding of tech other development habits like following coding/development standards, conventions (to which others adhere to and expect things to be in a specific way), proper design patterns will ease the development efforts -> leading to cleaner codebase -> less confusion -> thus effectively resulting/introducing in less bugs.
So the key rule in ensuring less bugs is - "Plan / learn all things, never go haphazard."
The next important thing is mastering debugging tools. Many developers do not take dedicated efforts to learn debugging tools. Every technology today have very sophisticated debugging tools. If you master one you can easily replicate the same skills in other technology. For example I first learnt Visual Studio features like Autos, Locals, Breakpoints, Conditional breakpoints, Watches, Thread Window etc. These feature concepts follow similar names in other IDEs. So I was able to very quickly use same stuff in Eclipse. The same follows in web debuggers like Chrome developer tools, Firebug. However there are many technology related stuff too like Profilers and element inspectors in web debuggers. Also Visual Studio 2012-2013 brings many new features that really need very dedicated efforts to completely understand them and practice them.
So thats my second point:
Debugging Tools
If you know technology well, you know what you want to accomplish (business scenario/ domain knowledge) and if you know how to track things when they misbehave, you are a king.
Also there is no doubt there are these obvious factors - experience and practice. But more conscious you are while learning and developing more quicker you will be in tracking things.
As a personal experience - when I was working a lot on JSP, Expression Language and related stuff I was able to tell them what might be going wrong just by listening to their problem behavior. So soon you start recognizing things quickly.
And whenever I stuck in some weirdly behaving code, I put breakpoint before it, hit debug, when breakpoint is hit check if all locals and globals have desired value and then step through each line looking for any changes that happens to those locals and globals.
Finally we have google: attach "best practices" to technology name, hit search and keep reading like this.
A trick or something? Well sort of - breakpoints and step throughs always helped me. Sometimes when I dont understand whats going wrong I take snapshot of suspicious behavior I find (but dont understand completely) while stepping through and put that snapshot with explaination on stackoverflow. :) Or else you can use tools like JSFiddle to explain problem in action. After all what you want is to get things fixed quickly and properly. ;p
These links may help you
