Debugging by Thinking and Professor Solomon

Previously, I wrote a blog describing my old debugging technique juxtaposed to how book Debugging my Thinking discusses a more Sherlock Holmes way of approach bug finding. However, the textbook describes more then one approach to thinking about debugging then just Sherlock Holmes. The text describes the methods of Professor Solomon's 12 steps to finding lost objects and how you can use the same thought process to locate bugs in code. Today I'll be analyzing those 12 steps, how they can apply to game development programming, and any thoughts I have about them. 

When applying Professor Solomon to debugging, you have to try to make an analogy between lost objects, and software defects. The lost object is an action of lack of action occurring in some unknown location. The visibility of that object is understanding how and where that piece of code causes the symptom. 

The Methods of Professor Solomon

• Don’t look for it
• It’s not lost, you are.
• Remember the three c’s.
• It’s where it’s supposed to be.
• Look for domestic drift.
• You’re looking right at it.
• The camouflage effect
• Think back
• Look once, look well
• The eureka zone
• Tail thyself
• It wasn't you.

Don't look for it

Don't start looking until you have an idea where to look. This is debugging by thinking! Not by hacking code and hoping stuff will work. Don't look at source code once you find a defect and don't look at output once you found or received evidence of the defect. Instead:

• Make a list of criteria that will qualify or disqualify sections of code.
• Make a list of similar defects you have seen in the past.
• Make a list of root causes and try to narrow down possibilities.

Once you have your list, start narrowing down possibilities. Remember, it is about knowing how to look, not where to look.

It's not lost, you are

Bugs are accidental and a behavior that is as yet unexplained. When looking for bugs, it is important you use a logical system for narrowing down your possibilities and finding it. It is important that you use a system for searching. If not, you will waste a lot of time, effort, and sanity, looking for it. Use a system!

Remember the three C's!

To find a bug, you have to be in the right mindset. There have been to many bugs I have chased and chased when frustrated, only to end up wasting my time. The three c's are:

• Comfort
• Calm
• Confident

It is important to be in a healthy state of mind and body, especially when tackling those bugs that has taken up days of a teams time. Drink plenty of water, breathing exercising, listen to calming music, take short breaks, proper lighting, etc. When you are physically and mentally capable of conquering bugs in code, chances are you will find them faster.

It's where it's supposed to be

When a piece of code is causing a bug, that bug isn't moving anywhere. It is exactly where it is supposed to be. But how can we find it? Using deduction, we can find where the bug IS NOT located. Try to narrow down locations where you can know, for certain, that the bug is not located, you can save yourself a lot of searching and stress. Remember, the bug is exactly where it is supposed to be, you can use that logic to narrow down where it isn't, and find it.

Look for domestic drift

Most bugs are normally found in the place you last modified. However, that does not mean you should right away look there. Use deduction to determine the root of your problem. When there is a defect, it will generally have a root point where it defects, then it will cause a trickle down effect where it causes a sequence of problems. Look for those kind of drifts. As a tip, try making a flow chart that illustrates the flow of data in your suspected area to try and narrow down what might be causing the issue. 

You're looking right at it.

During third year, I had a bug where items were not being properly parented. I had skimmed my code a hundred times but didn't see the problem. When trying to locate a bug, remember, you may be staring right at it and not realize that is the bug! Before looking for bugs, try explaining the bug to a friend or co-worker. Write down, logically, what is supposed to happen step by step and eliminate impossibilities. Narrow down your problem to a section of code and look viciously. 

The camouflage effect

I do not believe I have personally experienced this problem, but it is something to beware of. If you are absolutely certain you have narrowed down a problem to a key area, but cannot determine what may be causing the problem, consider that there are other factors that can place a problem out of view. For example:

• Preprocessor macros
• Procedure Calls
• Exception handling
• Complex language constructs (C++)

Think back

This section only applies to code you created. Try to think about what you did in terms of changes, and how that would alter the flow of logic you were intending to create. What is best for this section is to create versions of your code frequently so you always have a backup to look at. Also, commenting your code frequently, and providing large blocks of comments that describe changes, helps. It can give you a good idea of what you intended to do which can subsequently help you narrow down a list of problems you should create. 

Look once, look well

I wish I followed this one better. I mentioned earlier I had a problem with parenting in a game I was making in third year. I looked in so many different cpp files that it was giving me headaches. What was worse, was that I looked at the same spot several times, even when I thought it wasn't the problem area. When it comes to debugging, look once, look well. 

At each potential problem area, use all relevant tools to help find the bug. As mentioned before, also keep different versions so you can always go back and look. However you have to be wary when taking this advice. Make sure that, when you do look, you either confirm or eliminate the possibility of the problem being in that location. If you simply do not find the bug, check your other potential problem areas. If you know the problem is in that area, look again and try to understand the logic of what the program is supposed to do.

The Eureka Zone

More often then not, bugs develop where they should, others occur in the immediate vicinity. The textbook describes two types of displacement, physical and temporally. Temporally displaced problems are described as:

• Recently modified variables
• Recently executed statements
• Procedures closest to the call stack

Physically displaced problems often have to do with pointers. This is what the textbook suggests:

• Suspect variables in the same heterogeneous storage construct as the variable in which the problem became visible
• Suspect references that are on the call stack at the same time
• Suspect references to storage allocated on the heap at about the same time as the variable in question. 

Tail Thyself

Certainly the fanciest sounding tip and perhaps one of the most important. The concept is simple, tail exactly what you did and how you got to the point you are at. Keep versions, code comments, flow charts for logic, even if you have a written description of what you wanted to achieve, anything that can make you follow in your footsteps to help you narrow the problem down. Using revision software is critical for this step.

It wasn't you

After your herculean effort to try and figure out your problem, it may be reasonable to assume that you're not the cause of the defect. This one only applies if you're working with other people, or some other software development kit. With this problem, ask questions and do some looking around to see who or how the problem came about. If it is someone else in a group, then simply ask them. But make sure to have at least tried to narrow down the problem and create a bug report that is useful to that person. If you're using a SDK, then create a test case to demonstrate the problem and ask a thorough question. No matter how dumb your problem may be, never be afraid to ask.

Conclusion

When debugging, it is important to look at bugs as lost objects that you have to find. Using simple logic and a systematic way of finding bugs, you can reduce your stress, increase your productivity, and simply have more fun coding. I would say the most important take away from Professor Solomon's tips are to have a system for searching and remaining calm, comfortable, and confident. Thank you for reading, I hope you enjoyed my latest post!