I recently heard an interview with Martin Fowler on the Ruby Rogues podcast. He pointed out a few things about the process of refactoring that I haven’t thought of in a while. Based on that interview and what I’ve read and learned elsewhere about refactoring in the past few years, I decided there are a… Read More »
Between my earlier career in electronics and my current career in software, I have found a number of questions that have been helpful in troubleshooting problems reported by others. None of these questions are original to me. My wife described troubleshooting a hardware problem over the phone and mentions some of her troubleshooting questions. I… Read More »
Back in February, I ran across the post robkinyon on Perl: How useful is a debugger, really? and was again reminded of the great debugging debate. I thought about commenting on it at the time, but I got distracted. Well, Matt Trout reminded me of it again today with his post Simple Debugging. So, I… Read More »
In the previous four articles in my Unintuitive Multithreading series, I focused mostly on design of a multi-threaded application. This time, I plan to cover a few techniques that I have found helpful in troubleshooting multi-threaded applications. To some extent, the normal techniques you have used for troubleshooting will work in a multi-threaded program. But,… Read More »
In LinuxDevCenter.com: Tales of Optimization and Troubleshooting [Jun. 03, 2004], Howard Feldman presents three examples of troubleshooting and fixing bottlenecks. One thing I really like about this article is the methodical way the author goes about solving these problems. Having tried to teach troubleshooting to entry-level programmers, I know that it is very hard to… Read More »
One of the fundamental laws of the universe could be called the Law of Unintended Consequences. This law is as universal as Murphy’s Law, but not as well recognized. To me, the gut-level understanding of this law is one of the things that shows the difference between a really good programmer and someone who just… Read More »
In my weblog entry from a couple of days ago More Thoughts About Debugging, I forgot to add the information that prompted me to write in the first place. I was looking around a few weeks ago and found a series of links providing various pieces of debugging and troubleshooting information.
Earlier in this weblog, I listed some of my basic troubleshooting rules. I thought it was probably time to come back and spend a little more time on this topic. I plan to expand on the points I made earlier and add a few more thoughts along the way.
Here are a few basic rules of troubleshooting and debugging. Divide and conquer (always) 50/50 tests are best Verify can’t happen cases with a test Steady progress is better than random guessing If you guess and fail, go back to #1. Don’t try to keep guessing. I’ve been trying to formulate a good set of… Read More »