Being able to solve problems and fix bugs is probably high on the list of things that make a programmer a good programmer. These days programming is assisted with many tools and techniques. Stepping through code using advanced IDEs and debuggers find many issues before they become issues. Intellisense, code completion and syntax highlighting also reduce bugs before they can become bugs. Exception handling and error logging help a lot when issues occur in programs. Testing frameworks and methodologies help us to validate code and functionality in addition to lessening the introduction of additional bugs.
What happens when all of that fails or when we are given an application we are not familiar with or is not debug or test friendly? What types of non technical techniques do you use when attacking a difficult issue? Here are 10 things I find myself doing when confronted with a hard to find bug.
Compare files and environment. Make sure your code is exactly the same as the code where the issue takes place. If possible make sure your environment is also the same. Pay attention to configuration and versioning. Sometimes it’s not the code, but mismatched versions.
Try to keep things simple. Some of the worse bugs are the ones with simple solutions. If you find yourself coming up with complicated solutions to fix a bug step back and consider whether things really need to be complicated.
Don’t rush. Not many people work better when they rush. Take enough time so that you don’t skip over obvious issues.
Keep your users in mind. As a programmer we tend to know how a program works and will often avoid doing things that will break things. Trying to remember that users will always do things in a way that was not expected can help to open up possible issues. Make sure to get detailed reproduction steps and details about the user’s environment. I always try to remember the Who, What, When, Where, Why and Hows of an issue.
Remember that if something is going wrong the majority of the time it’s not the computer’s fault. We may sometimes come across an error where we think it’s an issue with the framework or something out of our control. Unfortunately it’s more likely there is an error in our code. Remembering this can prevent going down paths not related to the issue.
Do things an alternate way. If the functionality is simple enough explore doing it an alternate way. This will help to uncover what the program needs to do. If your alternate way exhibits the same issues you can narrow down the causes. Even better if your alternate way ends up working. Even if you don’t write any alternative code, just thinking about it can help to solve the issue.
Break things down. If you have unfamiliar or complicated code it may help to break it down into its simplest parts. Take out everything except for the basic functionality and build back up to see where an error is coming from. Sometimes it helps to isolate code. Take it out of the application and put it into an empty application to see what happens.
Have someone else look at the issue. Sometimes focusing on an issue results in focusing on an entirely wrong area or becoming blind to an obvious bug. Having someone else look at the issue can bring new things to light.
Break things. Breaking code can sometimes help you to understand code far better than only reading or stepping through code. Like reading a book we tend to overlook things that we have seen countless times before. Breaking something on purpose can help to break out of the mentality that you think you know how something is working and open up new ways to attack the problem.
Take some time away or sleep on it. This may not be an ideal method when you have a deadline, but many times taking a break from trying to fix a bug results in fresh perspective needed to find the solution. Resting your brain and destressing also helps.
Do you have any techniques that you use to make those invisible bugs visible?