Simple and obvious first
August 12, 2008
Logically, when you’re trying to debug an issue, you should start at the bottom. The simple answers are the easiest and the quickest, and let you get back to solving the real problems. Unfortunately, something usually comes between you and the easy answers: assumptions.
In our ever-present quest to go faster and get through things quicker, we cut corners, we make dumb mistakes, and we take on faith that others have performed due diligence so that we can start with high-level troubleshooting.
Having been a tech support agent for years, I’m acutely aware of this, and having been a sysadmin for over half a decade, you would think that I would be used to this situation, but that’s not the case. Oh, how I wish it were.
The reason that I bring this up is that yesterday I spent a couple of hours troubleshooting a missing set of quotes. I know, I know, how can you spend a couple of hours fixing something that obvious? It started with a simple issue: A shell script wasn’t passing the right filename to a program that it called.
I was brought in to figure out a way to get an argument to the script passed to the program correctly. I was given the example:
$ shellscript.sh arg1 arg2 “/path/to/file with spaces in name”
Inside shellscript.sh, a program was called like this:
/path/to/program $1 $2 $3
although I didn’t know that at the time. I solved the first problem, that the argument to the shell script wasn’t being interpreted correctly.
I eventually wrote a slick for loop to handle the arguments without breaking the filename into separate tokens. After testing it, I presented it to the person who asked me to look at it. After installing it into the program, it still didn’t work.
By this time, he was tired of dealing with it and asked me to work on the actual script. Of course, I looked at the script, saw the above line of code, and added quotes around the $3.
Obviously, the script worked perfectly after that.
My mistake was to assume that the script was written right and that the real issue was the one I was given. It might have taken 30 extra seconds to look at the contents of the script in the beginning. But I didn’t, and lost a couple of hours for my trouble.
Let this be a lesson to me. And you. Learn from my example, and verify your assumptions
Posted in General
Email me
content rss
August 12th, 2008 at 10:01 am
Oh how familiar that sounds!
But there is an effort-reward system here that might explain why we do it.
The number of times you bother to check something that turns out to not need checking costs you time. This time adds up. In your head you may estimate this time (badly) as you go along and eventually realise that your wasting time and could get to an answer much quicker by cutting corners (as you mentioned).
Soon enough you are saving time…
…until something comes along that can’t be solved by cutting corners because it’s the corners that are the problem (your story). The problem with this scenario (and the reason why I think we promote checking the simple and obvious first) is that your effort-reward is now decreasing exponentially (inverse) and you’ve spent 2 hours on something that should have taken 30 seconds. BIG waste of time and in a show stopper that can cause some serious downtime and fallout.
This is my attempt to help explain why we (I) act irrationally!
Craig
August 12th, 2008 at 10:15 am
Craig,
You’re right, we trick ourselves into thinking we’re clever by taking these shortcuts, then the hammer drops
Thanks for the comment!