Working a great deal with blacklists, I am frequently trying to isolate and identify problematic code. For example, a blacklist implementation may suddenly prevent a certain type of page from loading. In order to resolve the issue, the blacklist is immediately removed and tested for the offending directive(s). This situation is common to other coding languages as well, especially when dealing with CSS. Identifying problem code is more of an art form than a science, but fortunately, there are a few ways to improve your overall code-sleuthing strategy.
Firstly, think. I know this sounds trivial, but too many times do we as designers and developers get trapped into working as fast as possible, leaving our brains on “auto-pilot,” and immediately turning to Google as soon as something goes wrong. When it comes to diagnosing problematic code, your most valuable tool is your own mind. Take some time to do some critical thinking about the situation. What do you know about the issue? Has it been encountered before? What are the different components involved? And so on. Many times, I have found a relatively quick solution by simply slowing down, defining the issue, and assessing the variables.
Secondly, check the obvious. Working at a rapid pace requires us to rely on heuristics and algorithms to facilitate expedient production. Unfortunately, this way of thinking generally relies on taking “mental shortcuts,” working in the present, and focusing on singularities. This modus operandi excels when events unfold according to plan, but leaves us clueless when unexpected snags pop up. A good way to transcend any momentary disorientation is to stop and review the basics. You know, those well-known and obvious things that are usually forgotten about whilst working diligently with higher level operations. Things like: “Is this the most recent version of the file?” “Is the script even compatible with IE6?” “Did I forget a closing bracket?” “Is the computer plugged in?” You know — the basics.
And finally, the “halving method.” This technique is absolutely great for isolating and identifying problematic directives in blacklists, firewalls, and other behavior-altering portions of code. Additionally, I have used this method in lengthy stylesheets for determining which CSS declarations are causing unexpected behavior. The halving method basically works just like it sounds: when encountering problematic portions of code (such as a blacklist, firewall, or stylesheet), isolate the offending directive(s) by first removing one half of the code and checking for desired functionality. If things are still not working, remove another half of the code and test again. Wash rinse repeat. Then, as soon as proper functionality returns, replace the only the last portion of code that was removed and continue the process. Very quickly, usually after two or three iterations of this process, the problematic code will be easily identifiable.
Update / more info
For a good walkthrough of the halving method, check out The Perishable Press Halving Method. Thanks to Anders Vinther for the write-up :)