Banner
    Detectives and Debugging
    By Samuel Kenyon | July 16th 2012 01:38 AM | 2 comments | Print | E-mail | Track Comments
    More Articles
    All Articles
    About Samuel

    Software engineer, AI researcher, user experience (UX) designer, actor, writer, atheist transhumanist. My blog will attempt to synthesize concepts...

    View Samuel's Profile
    Debugging a program--or any system, such as a robot--often involves reducing the amount of unknowns until only one culprit is left. The situation is like a mystery story. A detective interrogates all the suspects and gathers clues until everybody but one suspect has an alibi. Along the way various red herrings lead the hero astray. But with sufficient confidence that there must be a logical explanation, the mystery is eventually solved.

    Fictional detective Hercule Poirot, here played by Peter Ustinov in Evil Under Sun (1982)

    Fictional detective Hercule Poirot, here played by Peter Ustinov in Evil Under Sun (1982)

    Comments

    MikeCrow
    While this is true, In many cases one really needs to confirm the error by fixing it, testing the fix, and then restoring the error to make sure the problem comes back. This is really important when you're made more than one change while trying to fix the bug.
    —
    Never is a long time.
    Mi Cro | 07/16/12 | 10:55 AM
    SynapticNulship
    Yes that is true. Typically in bug fixing and mystery solving you go through hypothesis / test / collect-more-data cycles. If you think you've solved it, you often have to try it unfixed again to make sure the error happens again, as you say. If it's a very difficult problem and/or you can't reduce the number of changes/variables at play and/or it's an intermittent error, then you may have to write special tests to generate the needed data for a hypothesis, then re-test after fixing for that theory, revert it and retest to make sure the error returns (or happens at the previous frequency).
    Samuel Kenyon | 07/16/12 | 11:11 AM