Comments on: The importance — and challenges — of debugging http://itknowledgeexchange.techtarget.com/software-quality/the-importance-and-challenges-of-debugging/ A SearchSoftwareQuality.com blog Wed, 25 Nov 2009 06:06:41 +0000 http://wordpress.org/?v=2.6.2 By: Dvlprem http://itknowledgeexchange.techtarget.com/software-quality/the-importance-and-challenges-of-debugging/#comment-25 Dvlprem Tue, 23 Jun 2009 08:31:34 +0000 http://itknowledgeexchange.techtarget.com/software-quality/the-importance-and-challenges-of-debugging/#comment-25 Veru Good Article, It's really useful for me. I am doing a bit on research about 'Debugging' and i found also macrotesting www.macrotesting.com to be very good source for software testing. Thanks for your article Prem 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

]]> By: Tuomoks http://itknowledgeexchange.techtarget.com/software-quality/the-importance-and-challenges-of-debugging/#comment-7 Tuomoks Mon, 06 Oct 2008 17:33:03 +0000 http://itknowledgeexchange.techtarget.com/software-quality/the-importance-and-challenges-of-debugging/#comment-7 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, 24x7 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! 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!

]]>