Russel, >I would have thought it patently obvious that debugging a program is >directly analogous to scientific experimentation: > > 1. Create an hypothesis about the bug > 2. Design a data/test framework in which to extract information > 3. Execute constructed test and obtain data > 4. Relate new data to hypothesis to create information (or not) > 5. Decide whether bug is fixed > 6. Goto 1 if necessary.
This is certainly one approach and the one favoured by most developers. However, there is an method that often locates the problem in less time. It uses binary chop to narrow down the fault to a few dozen lines of code and explicitly requires not forming hypotheses (I find they distract and lead down too many blind alleys if formed to early). Over the years I have tried to teach this method to a number of developers. While agreeing that the method generally leads to a much faster solution of problems, they don't like using it. The urge to create hypotheses seems to be very strong. Using a binary chop approach provides no sense of direction, which is something developers seem to like to have (even when it leads them down blind alleys). derek -- Derek M Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:[EMAIL PROTECTED] Applications Standards Conformance Testing http://www.knosof.co.uk - Automatic footer for [EMAIL PROTECTED] ---------------------------------- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
