Debugging - a dark art?

I just made a post worthy of Captain Obvious, suggesting some things that the OP could do to proceed with some debugging. Suggestions that I'd be mildly ticked to receive myself because they are well, so bleedin' obvious. But apparently they aren't.

Perhaps I've been writing software too long, but I consider debugging skills to be basic life skills; if you come home and flip the light switch and nothing happens, you debug a bit before you call an electrician. Bulb Ok? Power out? fuse/breaker flipped?

How then do we see so many posts where folks haven't even taken a single step down the debugging path? Are they already overwhelmed with the complexities of the coding they've done? Does simply it not occur to them? Are they unaware of the tools (limited though they may be) that can be used?

I wonder if a section on the subject in Nick's sticky thread would be helpful.

This is an important question that I think about a lot, and I'm glad you asked it.

I think the emotional aspects of debugging are often overlooked. Discovering that the program you created is malfunctioning has an emotional dimension, right?

Consider the five stages of a bug:

  1. Shock
  2. Denial
  3. Anger
  4. Bargaining
  5. Acceptance

The helpless ones you are describing are stuck in shock/denial. That is why it is so hard to direct their focus and attention.

The frustrated ones are stuck in the anger stage. We've all been there. Kind of hard to focus.

It's the ones who are past the anger and looking for answers/bargains that we can help with technical advice.

In my view, people stuck in stages 1-3 actually need emotional / social support more than technical support, until they can get back to the state of mind required to articulate the problem and accept guidance to focus back on it so they can solve it themselves.

Would be interested in other thoughts on the matter.

-br

if you come home and flip the light switch and nothing happens, you debug a bit before you call an electrician. Bulb Ok? Power out? fuse/breaker flipped?

You left the important part out, wildbill: flick the switch off and on a bunch of times in the hope that the result will differ one time and the light will start working. What a colleague of mine used to call POPO.... power off, power on.

One day a few years back, my next-door-neighbour asked my wife if we knew when the power was coming back on. My wife replied that as far as she knew our power was on, but checked a light and yes it was. My neighbour had gone the whole day, literally, with no power and hadn't checked her breakers. She assumed a) it was a power company problem and b) that we would have reported it.

"Learned helplessness": A state of cultivated denial caused by the assumption that the problem is someone else's to solve.

-br

So, if debugging is the art of finding and removing errors in code, that must mean programming is the art of putting errors in and we should refer to programming as "bugging".

imho Debugging is the art - science? - of finding the errors in code (and/or hardware), the analysis of why the application is behaving other than expected / intended. The rest is fixing. Debugging and fixing is not always done by the same person. I see in complex cases you have pair/group debugging and single person fixing quite often.

I recognize the 5 stages billroy mentions, but there are more:

  • stage 0: Unaware (ignorant?) and
    ..
  • stage 6: the ability to recognize and // after coding
  • stage 7: the ability to prevent and // while coding
  • stage 8: the ability to predict. // before coding

example of 8: I know that I make mistakes with complex boolean expressions, so I can predict that there will be (big chance) bugs in it
maybe 7 and 8 should be swapped?

Probably there will be a few more (sub)stages but I'm no shrink :wink:

Weep for humanity:

JimboZA:

if you come home and flip the light switch and nothing happens, you debug a bit before you call an electrician. Bulb Ok? Power out? fuse/breaker flipped?

You left the important part out, wildbill: flick the switch off and on a bunch of times in the hope that the result will differ one time and the light will start working. What a colleague of mine used to call POPO.... power off, power on.

Because there just might be an oxide buildup on the contacts....
I've actually done the same basic thing shoving connectors (sometimes on boards) in and out and gotten $#!+ to work.

BTW, what's this Dark Art business? Is sacrificing components while chanting "Murphy, Murphy!" and "Go for smoke!" 'Dark'?

"bugging"

So THAT's what I do, good to finally put a name to it. :slight_smile:

I was in a truckstop the other day, there was a truck there that wouldn't start, I spoke to the driver and he was distraught because he needed to get into the city for whatever. It was clearly an electrical problem so I asked if he'd checked the fuses. No he hadn't and he was waiting for a $X00 callout from a mechanic who couldn't get there for a few hours.

WTF?

"Learned helplessness" indeed.


Rob

JimboZA:
You left the important part out, wildbill: flick the switch off and on a bunch of times in the hope that the result will differ one time and the light will start working. What a colleague of mine used to call POPO.... power off, power on.

Power switches are nondeterministic, therefore the POPO approach often works!

JimboZA:
So, if debugging is the art of finding and removing errors in code, that must mean programming is the art of putting errors in and we should refer to programming as "bugging".

If that is the case then we should end up with nothing after we find and eliminates all the bugs from our programs.

I think programming is expressing your idea in every necessary detail with bugs in them cause your idea is partly flawed and your execution is partly flawed. After debugging, you will have a working implementation of your modified idea with less bugs.

I think programming is expressing your idea in every necessary detail with bugs in them cause your idea is partly flawed and your execution is partly flawed. After debugging, you will have a working implementation of your modified idea with less bugs.

I like this definition. I marked the things that meet my experience in bold.
I can think of 1 experience I had you do not explicitly mention. Adding that to the definition gives me.

Programming is expressing your idea in every necessary detail with bugs in them; cause your idea is partly flawed and your execution is partly flawed. After debugging, you may end up with a working implementation of your modified idea with less bugs.

best regards
Jantje

Thanks Jantje! Just my life experience. Just my most recent experience (not exactly debugging code): I plugged in an AC adapter and used it to power a motor shield for my project. I then ran some motor test code with "motor" (just two LEDs twisted back to back with a serial resistor so I can see green for forward motor and blue for reverse). For quite a few trials I can't find why the motor won't move. Out of frustration I unplugged USB and tried to power the thing with ac adapter, which is when I realized my board is not powered at all. Checked the power strip, I only had one conductor plugged in the socket and left the other one out (was fumbling with the adapter without enough lighting). Easy enough, when power is supplied, the motor starts to turn. I think if I have learned anything over my almost 3 decade programming experience, I learned to not trust myself but it is hard to do.

Not at all computer-related, but my f(l)avourite debugging story, ever.

AWOL:
Not at all computer-related, but my f(l)avourite debugging story, ever.

Awesome! Thanks for sharing.

AWOL:
Not at all computer-related, but my f(l)avourite debugging story, ever.

I actually had something similar happen with my truck. Every time I stopped at a store in this one specific town next to mine, my truck would either start hard, or not start at all. It only happened at stores in that town, and I never had a problem anywhere else. My friends always joked that it must be something in the air that my truck didn't like. It turned out to be a faulty oil pressure sensor. When heading to that town, I always took the interstate, which heated up the oil in my truck and lowered the oil pressure. In addition to that, the town was built on a wetland, so all the stores have slanted parking lots from the massive amount of fill that had to be trucked in to make the land suitable for building. The grade was enough to drain the already low pressure oil out of the sensor, and trigger a "low oil pressure" condition that is designed to prevent the engine from running in the event that it is severely damaged in a crash. Apparently the computer doesn't record that error condition, since it would normally be observable from outside the truck.

I was finally able to replicate the problem (by accident) in my driveway when I had one side of the truck up on ramps.