dan, it is a remarkable fact that "debugging" is a hardly existing concept in software engineering research although programmers spent a large share of their time (maybe 10-90%) debugging.
i would characterize debugging as a by and large implementation activity that is triggered by a freshly coded program that shows unexpected behaviour during execution. while initially debugging is concerned with finding a bug and fixing it, debugging frequently encompasses all the activities found in an SDLC: requirement elicitation, analysis, system engineering, design, implementation, verification and validation. however, those activities are not systematically (for a bystander it would appear randomly) executed. following beizer and my own experience, during debugging the program changes its nature from an object under investigation to a subject of the programmer's eagerness. perhaps it is the easy production of a new "final" variant by running the compiler that stimulates this by and large unproductive spiral that is not that often observed in other disciplines. i try to avoid the need and time for debugging activities by proper analysis, prototyping, code review and extensive program trace logs. nevertheless, under time pressure i see myself resorting to debugging. best regards, gerold -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Dan Frost Gesendet: Dienstag, 2. Januar 2007 21:05 An: discuss@ppig.org Betreff: PPIG discuss: Hello / how we debug Hi, First - hello to the list. Second, my particular interest at the moment is around how coders debug. I've been struck by the lack of standard debugging skills taught compared to the diagnosis skills taught to medics, mechanics and other professions where diagnosis, prescription, and resolution are more or less rote. My angle on this, as it were, is largely day-to-day - debugging in a day-to-day coding environment. I mention this because I've discovered papers dating back decades stating what coders (programmers) should know, and if only they did! So, the theory is there, but the practice isn't dripping through. The reason I ask PPIG about this is that I think the Psychology - or the simple emotional effect - of being forced to solve a problem in 10 seconds affects the decisions many coders make. Having a mental framework which gets delegated most of the information gathering (what information is there, what causes might there be... etc) relieves coders of 90% of the decisions made during debugging. Any interesting research in this area? Any standard diagnosis processes (like differential diagnosis etc)? ... Cheers, dan ---------------------------------------------------------------------- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/