Debug Addicts

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

Brian W. Kernighan

One of the signs of a problematic software environment is that you see many developers in "Debug" mode. If the code is complicated and have no tests, the developer has no other option than to go into the code with a debugger, trying to understand what is wrong with the code (if he is trying to solve a bug), or how can he extend the code (if he is trying to write a new functionality to an existing component). Since "Debugging" is a very slow process, it takes a lot of time and the chances of finding a developer "debugging" is even larger.

What is wrong with Debug?
If debug is so wrong, then why do we have many debug tools. Sometimes the ability to debug is the main attraction of a tool (for example, MyEclipse writes JavaScript Debugger first in his feature list right after its WebSphere tools). In Java you can find many tricks to make the debugging process faster as; Hotswap (change the code while you debug and see the change instantly), Conditional break point (stop the debugger in a specific line only when a specific condition is happening), Remote debugging (connecting to a remote running application to debug) and many others. Debugging was never easier!

After all these enhancements "Debugging" is still a manual, slow, error prone that gives a very limited insight into the code. It should be used as a last option, where nothing else is working. 

What else can we do?

I see "Debugging" as a symptom to a sickness of complex and untestable code. The alternatives that a developer has to understand a code flow are:

• Code Review - when the code is written in a simple way, short and unique (doing exactly one thing) methods, no Singeltons etc., you can understand the code by simply reading it. I would also suggest that you will try to read your code as English sentences. If you succeed, it means that you used meaningful names for your variables and simple straight forward logic. If the code is messy and you need to "understand" it with a debugger, you can try to document it. It will help you to understand, and also help future generations, as they will probably have to spend a lot of time in this messy code.
  
• Good Logging - Using Log4J in a meaningful way of debug levels (Error, Warn, Debug, Trace...) and good messages can replace any debug session. Good logger can be found for every language including java script (Firebug for Firefox is great). 
  
• Good Tests - Good tests are like a tutorial, which explains how to use a class, a method or a component. It gives example to its input, its usage and expected output. Usually it is enough to understand what it does and how to do it. More than that, a developer can add input samples to a test to check for additional behavior, instead of debugging it.

I believe that tests are the best tools for code understanding, but it is not the only one.