Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Suspending Disbelief While Debugging

by dws (Chancellor)
on Dec 09, 2002 at 00:53 UTC ( #218415=perlmeditation: print w/ replies, xml ) Need Help??

Every so often a bug comes along that seems to defy logical sense. In these cases, the mindset we adopt determines whether we're able to solve the problem, or whether we run screaming into the night. Sometimes it's necessary to momentarily suspect disbelief and just go with the flow, probing for clues where we're sure they shouldn't exist or be significant.

Consider being presented with the claim that a given system can't send email more than 500 miles. Sounds nutty, right? Then read this story. There's no Perl content, but it's worth the read just as a reminder of how nutty life can get in tech, and how crazy sounding bugs reports don't always mean crazy users.

(Credit for the link goes to the 0xdeadbeef mailing list, viaBoingBoing)

Update: In the event the story gets slashdotted, there's always the google cache. Arrg. Not working. rinceWind provides this link, which works at the moment, and RMGir provides this link.

Comment on Suspending Disbelief While Debugging
Re: Suspending Disbelief While Debugging
by JPaul (Hermit) on Dec 09, 2002 at 05:34 UTC
    I find whenever I come across a bug in my own code that appears to defy logic or explaination, and its not immediately apparent what I've screwed up, then it inevitably falls into the category of a DUMB mistake.
    Just one of those things, I suppose, but everytime I come across something like this... I just know its something really stupid, and I'm just not thinking well enough to spot it.

    I'm kinda curious if the solution is the same for everyone else: Walk away.
    I leave the programme alone for as long as possible (And, generally, depending on how nasty the code is, the longer I avoid the issue) and when I return, I return afresh. I run the programme. I get the error. I do a little debugging, and bam. There it is.
    Hello, its Mr Wildly-Stupid-Muck-Up.

    Anyone else share this?

    JP,
    -- Alexander Widdlemouse undid his bellybutton and his bum dropped off --

      Usually yes, the same for me too. I once caught a *very* stupid error where I was trying to assign the match of a regex in which my regex didn't have anything in parenthesis. Of course I was writing code quickly and probably thought that was the direction I was going, but after a few words that would make a sailor blush and a few hours away from it, I found it in a flash.

      The only thing I've never been able to reconcile is when my windows machine gets wonky and code that has run perfectly before, suddenly doesn't run until I reboot. THOSE errors really get you. :)

      There is no emoticon for what I'm feeling now.

        Apparently there is a Moscow to Ulan Bator flight, however the airport at Ulan Bator freezes up every now and then.
        -- Chris Ebenezer

        Have they tried rebooting?
        -- Joe Zeff

        That's "Ulan Bator", not "Microsoft Lan Manager"
        -- Paul Tomblin

        Hey! In the 7 years I ran LAN Manager, I almost never had to reboot.
        It always rebooted whenever it wanted.
        -- Carl Schelin

        Makeshifts last the longest.

      Absolutely. Sometimes it happens when I'm debugging something and I get stuck, other times it happens during the design phase, when I'm trying to figure out data structures, etc. I find out that walking away is more efficient than sticking with it in many cases. Sometimes the answer comes to me on the ride home, or while I'm mountain biking, or mowing the lawn... then the trick is to remember the solution. I send myself emails, leave myself voice mails, or write the dreaded yellow sticky notes before that part of my brain is overwritten.
      I'm kinda curious if the solution is the same for everyone else: Walk away. I leave the programme alone for as long as possible (And, generally, depending on how nasty the code is, the longer I avoid the issue) and when I return, I return afresh. I run the programme. I get the error. I do a little debugging, and bam. There it is. Hello, its Mr Wildly-Stupid-Muck-Up.

      I would assume that is an approach that appears quite often amongst those here. It makes sense-you get handed a problem, many times with someone breathing down your neck for a solution. Like a battlefield commander, you look at the problem opposing you, skirmish along its lines in attempts to find where best to hit it, form your battle plan, attack with all your forces... and your attack fails. You regroup your forces, and charge it again... and again... and again. You continue to attack along the same lines, until your attacks form muddy ruts in which you get stuck, attacking the same point over and over. Then you withdraw-the cost has been too high for little to no ground gained. You regroup, refresh, focus on other things for a bit, possibly even get new intelligence about your foe and its actions. When you return to that problem, you now come to it with a fresh view, and seeing it anew, you spot a better target point, or think of a better attack plan, and execute it, winning the day.

      (Yes, do it all the time.)

Re: Suspending Disbelief While Debugging
by gjb (Vicar) on Dec 09, 2002 at 08:27 UTC

    I find that writing tests before writing the code to be tested helps to catch a lot of dumb mistakes. Also, writing a test for the obvious seems like a waste of time, but it may help preserve sanity in case of an acute attack of stupidity.

    It also helps to consider refactoring the code (there's always something smelly) since it forces one to rethink the code. It ties in with the Extreme Programming paradigma which represents some nice ideas.

    Just my 2 cents, -gjb-

Re: Suspending Disbelief While Debugging
by shotgunefx (Parson) on Dec 09, 2002 at 10:24 UTC
    Whenver I encounter an error like that, I assume it's me and keep hacking away. Only after exhausting the likely possibilities, do I move on to the improbables, the bugs in the code I'm coding in.

    I've been bit more than a few times but implementation defects. My first (and worst) experience was a 3d renderer I was working on. I was only programming a few years at the time.

    It used "psuedo-raycasting" to draw textured map roads (a racing game). Thousands of lines of C && Assembler (386, everthing was unrolled). I kept getting garbage at the horizon. It would just randomly change heights. I poured over and over the code, making sure it wasn't a "1 off" error. I just couldn't solve it. After a month of beating my head of the wall, I switched to other projects, periodically coming back to it and repeating the cycle.

    Then a few months later I came bace and fixed it in 10 minutes. The solution? I entered a blank line in the C source (to make an expression easier to grok). That's it. No other changes. I still don't understand exactly how it was breaking it but the source file's layout hit the compiler just so that it would cause it to compile slightly different even though the text (minus the newline) was exactly the same. After that, nothing is beyond suspicion. :)

    -Lee

    "To be civilized is to deny one's nature."
Re: Suspending Disbelief While Debugging
by adrianh (Chancellor) on Dec 09, 2002 at 16:41 UTC

    Many years ago a friend of mine was working on a mocked up ATM type system that ran over a serial line. This included some self-tests to make sure that the line was up and running okay.

    When writing the self-test code he kept hitting this problem where the working test line was being diagnosed as failing. Spent most of a day going over the assembler code in question. We got to the stage where we were questioning the serial driver hardware in the machines and were looking around for spares.

    Very late that day we finally thought to check that the test lead was actually working... You should have heard the howls when we realised we'd wasted most of a day on some dodgy wiring.

    I still look back at that and wonder at our complete inability to accept that a few hundred bytes of obvious code was working properly. We knew that it must be a bug :-)

    It proved a salutary lesson for me. Always try and disable your assumptions when debugging and look at what is actually happening.

      One of my biggest problems when it comes to debugging is not checking the simplest things first assuming they must be working. The problem must be in the code I just changed. I'll have something half torn apart before realizing an external switch is in the wrong position...

Re: Suspending Disbelief While Debugging
by talexb (Canon) on Dec 09, 2002 at 16:44 UTC

    I guess the best story I have in that genre comes from my first work term in Fall 1977, while debugging a multiplication routine in assembler.

    After running a few tests, it became clear than a Branch If Greater Than worked fine if the difference between the two operands was large, and it continued to work down to a difference of two, but a difference of one wouldn't take the correct branch. After checking and rechecking my work, I threw myself on the mercy of the harware engineer, who got out his scope and hooked it up to the backplace, then confirmed that there was 'some noise' there. He removed and reattached some wires, checked his work, and after that my code worked fine.

    --t. alex
    but my friends call me T.

    Update: Deleted a redundant 'after that' at the end.

Re: Suspending Disbelief While Debugging
by RMGir (Prior) on Dec 09, 2002 at 16:51 UTC
    Neither the google cache nor the original link work for me, but I think this will work.

    This reminds me of the time I was debugging someone else's C++ code, which returned a const char * from a conversion operator.

    The value was "magically" changing 2 calls later.

    It turned out the pointer being returned was to a buffer on the stack with enough other locals in front of it that the first call wasn't overwriting it...
    --
    Mike

Re: Suspending Disbelief While Debugging
by dingus (Friar) on Dec 09, 2002 at 18:38 UTC
    2 rules for troubleshooting
    • 90% of problems are caused at the physical layer
    • The first question to ask your user is "What (apart from nothing) has changed since it worked?"
    Then you get the other bugs caused by stupidity - such as the pure genius one I wrote on Thursday and found (late) on Friday where I broke something out into a subroutine and reused $_ without a local. Do not do this. Did you know that doing push @{$$_{$var}} when $_ isn't a reference anymore can cause your perl program to crash abruptly without even reporting anything on STDERR?

    Dingus


    Enter any 47-digit prime number to continue.
Re: Suspending Disbelief While Debugging (some more)
by dws (Chancellor) on Dec 10, 2002 at 18:08 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://218415]
Approved by PodMaster
Front-paged by PodMaster
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2014-12-26 03:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (164 votes), past polls