The Mindset

When I was just starting my way as a software developer I worked in a team writing simulators and other tools for testing engineers. Most of the tools I wrote were 100% my creation. I designed them, I wrote them, and I provided support for them. This gave me a chance to control almost every aspect of development (except, of course, for the requirements and the deadline). Most of the time it was a lot of fun. Most of the time…

One of my responsibilities was to provide support for one of our mythological creations. It was the it-can-do-anything-you-can-possibly-imagine simulator (but we just called it: the ICDAYCPI-Sim). Almost every testing engineer in our department used it. Needless to say that unlike most of the things I was responsible for, I didn’t design this tool, and I didn’t write it. In fact, for a whole year I didn’t even see it. Most of the time it worked perfectly well for most of its users. Most of the time…

Then, one morning as I opened my mailbox, my biggest fear became a reality. There, at the top of my inbox, was a mail with the subject “urgent fix needed in the ICDAYCPI-Sim”.

At first, I panicked. After a couple of minutes, I pulled myself together and did what every software developer in the world would have done: I fixed myself a strong cup of coffee. Then, I fixed myself another one. I went back to my desk and started to search the mythological project. Even that task was not trivial. “Good start” I thought to myself.

When I eventually found the project, I started to wish I hadn’t. I gazed at the IDE-less UNIX shell, which was filled with what seemed to be an endless list of C files. Each file contained thousands of lines. And naturally, there was not even a single README file to provide me a hint on where to start. I knew the fix I had to implement was extremely simple. I just had to change the length of some field in the parsing sequence. How hard could that be? Well, it can be extremely hard when you have no idea where to start looking for the relevant piece of code.

I stared at the screen for a few more minutes, and then I did the next thing that every software developer in the world would have done: I launched the debugger. A week later the fix was implemented (it took me two more days, though, to build the project, but that’s for another post).

***

Wikipedia defines a debugger as “a computer program that is used to test and debug other programs”. Debugging is then defined as “a methodical process of finding and reducing the number of bugs, or defects, in a computer program”. Now, let’s be honest: how many of us are using a debugger for things that have nothing to do with finding the source of a bug? Unfortunately, most of us do.

The debugger seems to be the number one tool for understanding a piece of code. Many of us use it whenever we come across a piece of code we don’t understand. This may be a legitimate approach when you have a badly written undocumented piece of code you have to work with. The problem is many of us keep writing such code because we subconsciously (or consciously) assume a debugger is the perfect tool for understanding code. Well, it isn’t.

Trying to understand a piece of code using a debugger, stepping into each line, and therefore reading each line in isolation, is a tedious and ineffective task. It’s like trying to understand a picture by seeing one pixel at a time. When code is self-describing and its high-level structure is intelligently documented, it is relatively easy for someone new to the code to find his way in it.

But there are even stranger uses for a debugger. Some developers, for example, use a debugger to verify that their code works correctly. The technique is quite simple. You write a simple main method to launch your code and provide it with some input. Then, you use a debugger to follow the execution of the code step-by-step. All this is done with various inputs and without any reported bug you are trying to locate. You are just “testing” your code. How long does each such test take to execute? Very long! Believe it or not, some developers out there use this technique as a replacement for automated unit testing. No, it’s not because the tests they want to use are hard to automate. It’s because they truly believe that using a debugger is the most effective way to test your code. Period.

***

To be honest, the way we use a debugger is just one example of a wider phenomenon. Many of us misuse tools. We think we are leveraging a tool by using it in some innovative way. But most of the time this misuse leads to a waste of valuable time and resources.

There’s a lot of room for innovation even when it comes to the way you use your toolbox. But what ever you do, you must always verify that you are on the right track. There’s nothing innovative in using a debugger for unit testing or for trying to understand the structure and logic of 100,000 lines of code. Unless, of course, you’re trying to come up with innovative ways to waste time.

This entry was posted on Tuesday, October 31st, 2006 at 3:41 pm and is filed under Code Quality, Development Environment, Testing, Tools. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.