2. December 2009 15:45
If you ever find yourself driving along US 20 just Northeast of Idaho Falls, Idaho be sure to look to the South at the small rolling hills because if you look closely, you might be able to pick out some small brown buildings huddled together amidst all the potato farms. It was in those buildings, early into my CS degree, where I learned my first valuable lesson in debugging.
I was sitting in the small Computer Science lab agonizing over a CGI Perl script. I had a problem. My variable was losing its value and I had no idea why. I would print out the value and then print it out again and the value was lost. I checked the code between the printings and nothing was doing anything suspicious to the value. As the hours passed, I was falling deeper and deeper into frustration. I had a depressing thought: How could I possible succeed at this profession when my variables can’t keep their values.
Looking for ideas, I did what every self respecting programmer did before Google existed and looked for some human help. No one was in the lab so I sheepishly made my way over to the professor’s office which was conveniently located just off the computer lab. This, after all, was a small college where professors weren’t self absorbed in their own research and actually talked to students.
Luckily, he was there and willing to help. We pulled up my program—which was a very busy thing with lots of variables. I jumped in trying to explain things to gain credibility. He immediately began to pull out chucks of my program and put them into a new Perl program to run. Then we would verify the piece ran as it should. We continued to do this until the problem was discovered; my variable was misspelled ever so slightly. Perl, of course, is a dynamic language and had simply created a new variable instead of using the one I wanted.
I was embarrassed—especially considering the problem was discovered in under 5 minutes—but I learned a lesson. When something is not working and the program or function has lots of working parts you must simplify. Creating a new program from scratch and pulling over code to run eliminates all the noise from the surrounding code.
I have used this technique effectively countless times since. Still, I am surprised sometimes by professional programmers not using this technique when trouble shooting issues. They will toil with the whole beast of a program trying to fix the issue but it is hopeless because there is just too much noise. Simplify.