StackOverflow: Debugging…. What is the moral of this?
By: Andrey Karpov
Tags: Tdd, Software Development, Software Engineering, Debugging, Programming

I came across a question on StackOverflow that sounded interesting to me. The readers started to downvote it, which means it may disappear soon, but I want to answer it. That’s why I’m writing this small post.

Now, the question is: What is the moral of this?

One great personality said once:

“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.”

Is it true? What do you think the moral of this?

My answer.

It feels like a kind of parable. Parables often show the world as seen from one particular perspective and do not necessarily reflect the truth (which is a relative notion anyway :). But parables do make you wonder — and that’s how they are helpful.

This case is no exception. Debugging is not always hard. But debugging is an extremely unproductive way of spending your working time. It’s one of the slowest, most complicated, and most expensive ways to find bugs. A much better approach is to prevent bugs rather than fight them. Debugging should be seen as the last resort, when a bug has still somehow made it into your code despite all the lines of defense you built up. And if you do resort to debugging, make sure you focus on applying practices that help detect bugs at the earliest stages rather than honing your skill of using the debugger (though it may be useful too).

Such practices of bug prevention or early detection include the following:

Keeping to the coding style. Companies normally have coding standards — these just should be kept up to date and allow for inclusion of new practices. This is especially important when the language you are writing in is rapidly developing. Google C++ Style Guide is an example of what a good coding standard should look like.

Pair programming. With two people working on the code, bugs are easier and quicker to notice. This approach does work, but it’s, first, expensive and, second, not comfortable to everyone. So I wouldn’t recommend it as a universal practice. But it does help keep most of the bugs away when writing new code.

Code review. In addition to bug fixing, code reviews allow developers to share knowledge with each other and discuss high-level issues. It’s an important and necessary practice. You just have to figure out how much time your team can productively spend on code reviews to keep the balance between quality and time consumption. Code reviews are thoroughly explained in Steve McConnell’s “Code Complete”.

Testing newly written code with unit tests. The more advanced version of this practice is called Test-driven development (TDD). Tests written along with the code to be tested help you almost immediately find and fix a lot of bugs. The practice of writing unit tests has one interesting side effect: since your classes and functions have to be tested, they tend to become simpler and less tightly coupled, which adds to the overall quality and readability of your code.

Static code analysis. It’s automated code review, so to speak, with the review being done by a software tool rather than a human programmer. On the one hand, software tools aren’t good at detecting high-level bugs in algorithms; on the other hand, they are excellent at detecting typos not easily noticeable to the human eye (examples: 1, 2, 3).

Such approaches as dynamic code analysis, regression testing, and others, should also be used. But these, unlike the previous practices, I consider the second line of defense.

So, “What is the moral of this?”

I think the moral is that it’s a very bad sign if you have to use the debugger to find bugs often. It means your whole development process wasn’t organized correctly in the first place. It can be improved by adopting the practices of early bug detection discussed above.