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/

Reply via email to