Why debugging is all about understanding • Hacker News Board

Re: Why debugging is all about understanding

#41

Post by ams6110 » Thu, Aug 06, 2015, 4:08 PM UTC

userbinator wrote: post #13

JustSomeNobody wrote: post #5

Writing code is about understanding, also. I've seen developers bang away at a problem for days and not be able to describe how it "works" in a code review. They just tried every crazy thing they could think of until it eventually returned results that looked correct. Don't be that kind of developer. For one, all the other developers are going to make you maintain that code for the rest of your life. Two, never be to…

I agree, understanding certainly can't be emphasised enough - I believe that a good programmer must always be able to understand enough to "mentally execute" - manually stepping through code, possibly with pencil and paper or a whiteboard, and making sense of the results at each step. There are some who argue against this, and their argument is effectively "if the machine can do it for you, why should you need to kno…

I tried telling a client once, "if you can't tell me what you want, how am I supposed to make the computer do it." Wasn't very well received.

Re: Why debugging is all about understanding

#42

Post by bcantrill » Thu, Aug 06, 2015, 4:22 PM UTC

While it's great to see more attention brought to debugging, some of this is just (for lack of a better word) insane. e.g.:

For searching in space, most programmers have done binary-search with commented code: comment out or bypass half of your codebase. Do that recursively until you nail down where (at which file, which function, which lines) the bug lives.

No, most programmers actually haven't done this for the simple reason that it's highly unlikely to work: most codebases with half of their functionality removed don't actually function. That this kind of lunacy is being asserted as authoritative is galling enough, but it gets worse:

When binary search doesn't work, you need more creative approaches. Consider brainstorming to enumerate even the wildest possibilities: for instance, maybe the bug is in some external resource like a library or a remote service; maybe there is version mismatch of libraries; maybe your tool (e.g. IDE) has a problem; maybe it is bit flipping in the hard disk; maybe the date and time library is sensitive to your computer's settings, etc.

This is advocating debugging by superstition, and it represents toxic thinking. When we have defects in software, we need to be strictly empirical in approach:

1. Make observations.

2. Think of interesting questions.

3. Formulate a hypothesis.

4. Develop a testable prediction from the hypothesis.

5. Gather data to test the prediction.

6. Refine, alter or expand the hypothesis.

7. Go to step 4 until defect has been driven to root cause(s)

If this sounds familiar, it is because it is the scientific method[1] to which we can credit much of modern knowledge and civilization. As to how this specifically relates to debugging, I touched on this in my recent DockerCon presentation[2][3]. Bringing attention to debugging is terrific -- but advocating superstition as a methodology is anathema to true understanding.

[1] https://en.wikipedia.org/wiki/Scientific_method

[2] https://www.youtube.com/watch?v=sYQ8j02wbCY

[3] http://www.slideshare.net/bcantrill/running-aground-debuggin...

Re: Why debugging is all about understanding

#43

Post by JoeAltmaier » Thu, Aug 06, 2015, 4:30 PM UTC

bcantrill wrote: post #42

While it's great to see more attention brought to debugging, some of this is just (for lack of a better word) insane. e.g.: For searching in space, most programmers have done binary-search with commented code: comment out or bypass half of your codebase. Do that recursively until you nail down where (at which file, which function, which lines) the bug lives. No, most programmers actually haven't done this for the sim…

Doesn't all that stuff you call 'toxic' actually fit in step 5? Lets not get hyperbolic about it. Backing out changes; setting breakpoints and interval-halving through a procedure to find where a value goes wrong; comparing library versions with working build is all good practice.

Re: Why debugging is all about understanding

#44

Post by bcantrill » Thu, Aug 06, 2015, 4:37 PM UTC

JoeAltmaier wrote: post #43

bcantrill wrote: post #42

While it's great to see more attention brought to debugging, some of this is just (for lack of a better word) insane. e.g.: For searching in space, most programmers have done binary-search with commented code: comment out or bypass half of your codebase. Do that recursively until you nail down where (at which file, which function, which lines) the bug lives. No, most programmers actually haven't done this for the sim…

Doesn't all that stuff you call 'toxic' actually fit in step 5? Lets not get hyperbolic about it. Backing out changes; setting breakpoints and interval-halving through a procedure to find where a value goes wrong; comparing library versions with working build is all good practice.

To be clear: the toxic bit here is the idea that you start with that first. Everything you describe is entirely appropriate when you have a hypothesis in hand, and you are using it as a technique to test it -- but I (strenuously) object to the idea that problems should be debugged by first randomly permuting the codebase.

Re: Why debugging is all about understanding

#45

Post by chrisseldo » Thu, Aug 06, 2015, 4:52 PM UTC

what tool is he using for the sketches

Re: Why debugging is all about understanding

#46

Post by ectoplasm » Thu, Aug 06, 2015, 5:09 PM UTC

bcantrill wrote: post #44

JoeAltmaier wrote: post #43

Earlier quoted context omitted.

Doesn't all that stuff you call 'toxic' actually fit in step 5? Lets not get hyperbolic about it. Backing out changes; setting breakpoints and interval-halving through a procedure to find where a value goes wrong; comparing library versions with working build is all good practice.

To be clear: the toxic bit here is the idea that you start with that first . Everything you describe is entirely appropriate when you have a hypothesis in hand, and you are using it as a technique to test it -- but I (strenuously) object to the idea that problems should be debugged by first randomly permuting the codebase.

Binary search is not random permutation. The hypothesis is "problem lies in this half of the codebase". Hey, if your test passes after commenting out some stuff, great.

Re: Why debugging is all about understanding

#47

Post by sosborn » Thu, Aug 06, 2015, 5:43 PM UTC

ams6110 wrote: post #40

Also a couple of tips for the beginning programmer: * You've almost certainly not found a bug in the compiler or libraries or language runtime (somewhat more possible if you're using alpha, beta, or dev versions of something). * Your CPU, memory, or other hardware are not defective. * You are not experiencing cosmic rays flipping bits randomly in your data. * The problem is most likely to be a mistake in your code. I…

> * You've almost certainly not found a bug in the compiler or libraries or language runtime (somewhat more possible if you're using alpha, beta, or dev versions of something).

This should be in bold type on every page of Stackoverflow.

Re: Why debugging is all about understanding

#48

Post by lisivka » Thu, Aug 06, 2015, 5:47 PM UTC

mhomde wrote: post #12

Over the years I've become more and more convinced that debugging has done a lot to develop my problem solving skills and analytical thinking in general. It's like being a full-time modern times Sherlock Holmes with the crime scene and tools neatly at your disposal. Usually breakpoints and stepping through code solves things pretty easily but some bugs can be real stumpers. Here's some of the tools I tend to use: 1.…

I am sorry, but it is contrproductive. It is better to invest time into better code, which will find and tell you about problem, because such code can be reused many times by whole team. Instead of playing Sherlock role, think: why your code allowed you to make that bug? Maybe you need to improve your code, add more test cases (or improve existing), add beter comments, add more examples, add more flexibility in configuration (so you can test program subsystems in isolation or in mock environment), use better tools, use toos for automatic verification of code, etc.

Your code is your debugger. If you will write properly, you will need not to run debugger at all, because code will explain problem to you (or to future user or administrator of your program).

Re: Why debugging is all about understanding

#49

Post by bcantrill » Thu, Aug 06, 2015, 6:06 PM UTC

ectoplasm wrote: post #46

bcantrill wrote: post #44

Earlier quoted context omitted.

To be clear: the toxic bit here is the idea that you start with that first . Everything you describe is entirely appropriate when you have a hypothesis in hand, and you are using it as a technique to test it -- but I (strenuously) object to the idea that problems should be debugged by first randomly permuting the codebase.

Binary search is not random permutation. The hypothesis is "problem lies in this half of the codebase". Hey, if your test passes after commenting out some stuff, great.

And if that hypothesis is based on data, great. And if there is no other alternative, fine -- but this technique should be viewed as a last resort (and an unusual one), not a first step.

Re: Why debugging is all about understanding

#50

Post by mwcampbell » Thu, Aug 06, 2015, 6:14 PM UTC

bcantrill wrote: post #42

While it's great to see more attention brought to debugging, some of this is just (for lack of a better word) insane. e.g.: For searching in space, most programmers have done binary-search with commented code: comment out or bypass half of your codebase. Do that recursively until you nail down where (at which file, which function, which lines) the bug lives. No, most programmers actually haven't done this for the sim…

I listened to your DockerCon talk on debugging. So in a server that can handle multiple concurrent requests (e.g. a web application server), should each unhandled exception abort the whole process (after delivering something like an HTTP 500 to the client) so the developer can do postmortem debugging on a core dump? That would cause all other in-progress requests to be aborted too, unlike simply logging the exception and moving on. But then again, maybe that would increase the motivation to root-cause every failure.