Share via

Whyline

  • Article

Brad Myers from CMU was here today giving a talk which included some details of the Whyline system, a debugger that allows programmers to ask questions about the behavior of their application in order to be able to figure out what the problem is (there's some discussion of the system on Slashdot).

There were many interesting points made during the talk. In the lab and field studies that Brad Meyer's group had run on how programmers debug, they found that when starting out debugging a particular issue, developers start by asking questions about the application behavior they are observing, as opposed to asking questions about the code that is being executed (or not as the case may be). So, they'll ask questions such as “Why isn't the error message being appended to the application log?” instead of “Why doesn't applicationLog.Write(someError) write the error message to the log?”

The reasons for this were that developers aren't completely confident about the particular line or lines of code that are responsible for the issue when they start investigating the issue. The implications of this in terms of debugger functions and features are pretty interesting because it indicates that one piece of the puzzle that developers currently have very little tool assistance for is in correlating program behavior to specific lines of code. Breakpoints, data inspectors etc, are all useful tools, but in order to be able to use these effectively, the developer needs to know what lines of code to place a breakpoint on, or what data to watch.

One other interesting point made during the talk was that “print statements are still the most popular style of debugging”. Perhaps this is because they are one of the only available features that help developers trace execution of their application so that they know what lines of code or what data they should focus their attention on.

Comments

  • Anonymous
    August 04, 2004
    The CLR could be enhanced to trace control flow, without having to even recompile. As long as the tracing was nicely indented according to function depth and filtered according to Assembly/type/class and regular expressions, it could be managed, and a very valuable tool. I often used similar tracing mechanisms in older OOP environments.

    It looks like the Whyline is specifically targeted toward non-programmers, or junior programmers, that do not use the scientific principle when debugging: hypothesize, change a single variable in the environment or scenario, confirm/deny hypothesis, reverse change. In the Whyline intro they say users were changing multiple things at once, none of which were related to the bug, making the behavior worse and worse. This used to be called "hacking" in the bad sense.