Home > IT Blogs > Software Quality Insights > The importance — and challenges — of debugging
« Traits of good software testers
Web application security more important than ever »
» VIEW ALL POSTS Oct 1 2008   3:43PM GMT

The importance — and challenges — of debugging



Posted by: Michelle Davidson
Software testing, Software testing tools, Software Quality, Debugging

Debugging is often challenging for programmers, so much so that many books have been written about it. One of the latest to hit the shelves is The Art of Debugging with GDB, DDD, and Eclipse written by Norman Matloff and Peter Jay Salzman and published by No Starch Press.

According to Matloff, debugging is challenging because “you’re looking for a needle in a haystack. And in many cases, the bug turns out to be in the portion of the program you’re most sure is correct!”

And that, he said, is one of the most common pitfalls programmers encounter. They’re sure that some part of a code is correct when in actuality that is where the bug is hiding. Additionally, Matloff said, some programmers will not use a debugging tool.

What can programmers do to avoid those pitfalls?

“In our book, we put forth a key guideline that we call the Principle of Confirmation, which says that debugging is basically a process of confirming that what you think really is true. Eventually you find an assertion that fails to confirm, and then you’ve likely pinpointed the location of the bug,” Matloff said.

Of the debugging tools out there, Matloff says the benefits open-source tools includes the ability for them to be used on any of the major platforms — Linux, Mac, and Windows.

“Thus you can have the same environment available to you even if you work on several different kinds of systems,” he said.

When asked if there are issues that make debugging more critical these days, Matloff said there is much debate about this.

“For example, some people think that strongly typed languages are “safer,” i.e. less bug-prone, while others believe that such languages complicate the code so much that they generate MORE bugs,” he said.

What do you think? Are some languages safer than others? Do you have any tips for making the debugging process easier?

AddThis Social Bookmark Button     Comment     RSS Feed     Email a friend

Comment on this Post


You must be logged-in to post a comment. Log-in/Register

Tuomoks  |   Oct 6 2008   5:33PM GMT

Debugging is (too often) difficult. IMHO not so much because of language, systems, etc but the environment. Very seldom an application can be debugged in production and if done in production there are many problems - maybe the rest has to be kept running, 24×7 systems!, avoid crashing the whole system, maybe it was just one of case and can not be replicated, etc - an of course it is in middle of the busiest time but you are three time zones away on a vacation day!. Fun? Unfortunately more and more common today - definitely not anything to give some junior developer.

Seriously, I may be old-fashioned but debugging is and should be the last option, the systems should be built good enough diagnostics, tracking and recoverability to survive maybe 9 our of 10 problems and the problems fixed later. Not happening any more, is it lack of systems design skills or just bad management - I don’t know but a little frustrating.

Languages and environments can make it easier or more difficult, often a lot. I belong to the group which thinks that the “managed” languages and systems make the debugging much more difficult - you just don’t know where the “root cause” for the problem is! Is it really a problem or feature in language system - seen that too often especially when the system version has changed!

Really makes my day when the language “specialists”, etc who have no idea of the system itself make changes and then the whole system starts misbehaving! And they still argue that the code is correct?

Mostly today in multi-threaded, multi-cpu and multi-node, asynchronous systems where the timing, memory access, interface, formating, etc problems can multiply very fast. Most (all?) developers start “debugging” the code instead of analyzing what, where, why, how, when, etc the problems occurred? Change the code just to get two more problems later on (maybe much later!) and now the original problem is hidden - time to 4th, 5th level support, i.e. they walk away and leave it to someone else to fix their problem(s)! Maybe I just hate cleaning other peoples mess?

So - debugging can be difficult but it can be made easy by correct design. Of course there always will be bugs which need debugging, no system is perfect, environments change, etc but it is almost as most systems have been developed in debugger just to get one special case to work instead using debugger just to find real problems? Meaning - change the environment means going back to debugger!

Enough complaining the lack of design - maybe complain the debuggers? Using debugger in EXEC8/TSO maybe -71 where you could execute in source format (or show the assembler/both), change the code (values, registers, etc), repeat some execution, save the code back to source, comment it, record the results, let the application to continue as nothing would had changed, etc - not many such debugging systems today? Too often the debuggers are depend (very heavily) on the development environment which is either not available in production or totally changes the run environment - not any more same as production!


 

Dvlprem  |   Jun 23 2009   8:31AM GMT

Veru Good Article, It’s really useful for me. I am doing a bit on research about ‘Debugging’ and i found also macrotesting <a href="http://www.macrotesting.com" title="http://www.macrotesting. " target="_blank">www.macrotesting.com</a> to be very good source for software testing.

Thanks for your article
Prem


 
Visit Software Quality Home |   Software Quality News  |  Software Quality White Papers  |  Software Quality Videos  |  Software Quality Resources