Amy J. Ko
Brad A. Myers
ABSTRACT
When software developers want to understand the reason for a program's behavior, they must translate their questions about the behavior into a series of questions about code, speculating about the causes in the process. The Whyline is a new kind of debugging tool that avoids such speculation by instead enabling developers to select a question about program output from a set of why did and why didn't questions derived from the program's code and execution. The tool then finds one or more possible explanations for the output in question, using a combination of static and dynamic slicing, precise call graphs, and new algorithms for determining potential sources of values and explanations for why a line of code was not reached. Evaluations of the tool on one task showed that novice programmers with the Whyline were twice as fast as expert programmers without it. The tool has the potential to simplify debugging in many software development contexts.
- Abraham R. & Erwig M. (2005). Goal-directed debugging of spreadsheets, IEEE Symposium on Visual Languages and Human-Centric Computing, Dallas, Texas, 37--44. Google Scholar
Digital Library
- Baowen X., Ju Q., Xiaofang Z., Zhongqiang W., & Lin C. (2005). A brief survey of program slicing, SIGSOFT Software Engineering Notes, 30, 2, 1--36. Google ScholarDigital Library
- Clause J. & Orso A. (2007). A technique for enabling and supporting debugging of field failures, International Conference on Software Engineering, Minneapolis, MN, 261--270. Google ScholarDigital Library
- Cleve H. & Zeller A. (2005). Locating causes of program failures. International Conference on Software Engineering, St. Louis, MI, 342--351. Google ScholarDigital Library
- Cooper K.D., Harvey T.J. & Kennedy K. (2001). A simple, fast dominance algorithm. Available at http://www.hipersoft.rice.edu/grads/publications/dom14.pdf.Google Scholar
- Eisenberg A. & De Volder K. (2005). Dynamic feature traces: finding features in unfamiliar code. International Conference on Software Maintenance, Budapest, Hungary, 337--346. Google ScholarDigital Library
- Ko, A.J. DeLine, R., & Venolia, G. (2007). Information needs in collocated software development teams. International Conference on Software Engineering, Minneapolis, MN, 344--353. Google ScholarDigital Library
- Ko, A.J. & Myers, B.A. (2004). Designing the Whyline: a debugging interface for asking questions about program failures. ACM Conference on Human Factors in Computing Systems, Vienna, Austria, 151--158. Google ScholarDigital Library
- Ko. A. J., Myers, B.A., Chau, D.H. (2006). A linguistic analysis of how people describe software problems. IEEE Visual Languages and Human-Centric Computing, Brighton, UK, 127--134. Google ScholarDigital Library
- Ko. A.J., Myers, B.A., Coblenz, M. & Aung, H.H. (2006). An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks. IEEE Transactions on Software Engineering, 32(12), 971--987. Google ScholarDigital Library
- Lencevicius R., Holzle U., & Singh A.K. (2003). Dynamic query-based debugging of object-oriented Programs, Journal of Automated Software Engineering, 10(1), 367--370. Google ScholarDigital Library
- Lewis B. (2003). Debugging backwards in time, International Workshop on Automated Debugging, 225--235.Google Scholar
- Liblit B., Naik M., Zheng A., Aiken A. & Jordan M. (2005). Scalable statistical bug isolation. Programming Design and Implementation, Chicago, IL, USA, 15--26. Google ScholarDigital Library
- Myers B.A., Weitzman D., Ko A.J., & Chau D. H. (2006). Answering why and why not questions in user interfaces. ACM Conference on Human Factors in Computing Systems, Montreal, Canada, 397--406. Google ScholarDigital Library
- Potanin A., Noble J., & Biddle R. (2004). Snapshot query-based debugging. Australian Software Engineering Conference, 251. Google ScholarDigital Library
- Sridharan M., Fink S.J., & Bodik R. (2007). Thin slicing. Programming Language Design and Implementation, San Diego, CA, 112--122. Google ScholarDigital Library
- Tassey, G. (2002). The economic impacts of inadequate infrastructure for software testing. National Institute of Standards and Technology, RTI Project Number 7007.011, 2002.Google Scholar
- Ungar D., Lieberman H., & Fry C. (1997). Debugging and the experience of immediacy. Communications of the ACM, 40(4) 39--43. Google ScholarDigital Library
- Wang T. & Roychoudhury A. (2004). Using compressed bytecode traces for slicing Java programs, International Conference on Software Engineering, Scotland, UK, 512--521. Google ScholarDigital Library
- Zhang X. & Gupta R. (2005). Whole execution traces and their applications. ACM Transactions on Architecture and Code Optimization, 2(3), 301--334. Google ScholarDigital Library
Index Terms
- Debugging reinvented: asking and answering why and why not questions about program behavior
Recommendations
Finding causes of program output with the Java Whyline
CHI '09: Proceedings of the SIGCHI Conference on Human Factors in Computing SystemsDebugging and diagnostic tools are some of the most important software development tools, but most expect developers choose the right code to inspect. Unfortunately, this rarely occurs. A new tool called the Whyline is described which avoids such ...
Debugging by asking questions about program output
ICSE '06: Proceedings of the 28th international conference on Software engineeringOne reason debugging is the most time-consuming part of software development is because developers struggle to map their questions about a program's behavior onto debugging tools' limited support for analyzing code. Interrogative debugging is a new ...
Extracting and answering why and why not questions about Java program output
When software developers want to understand the reason for a program's behavior, they must translate their questions about the behavior into a series of questions about code, speculating about the causes in the process. The Whyline is a new kind of ...
Reviews
Andrew Brooks
Are we witnessing the birth of a new interaction paradigm that is not only for software debugging, but also for working with software in general__?__ Whyline is a debugging tool for Java that allows the user to view and get answers to "Why did..." and "Why didn't..." questions about program output. During program execution, Whyline captures a trace that is then used to construct a user interface for navigating output history. Users move a slider back and forward in time and select screen elements of interest to expose "Why did..." and "Why didn't..." questions. In the provided proof-of-concept painting application, the user can view questions, such as "Why did thickness = 5__?__" and "Why didn't thickness change__?__" Whyline is nontrivial and makes use of static and dynamic slicing techniques, called graphs, and various other algorithms. Performance measurements indicate that Whyline is practical for program executions of no more than a few minutes. In a pilot evaluation study, when asked to locate a bug, Whyline subjects were twice as fast as a group of Java experts using Eclipse 2.1. Ko and Myers concede, however, that this study has limited generality, since it involves only one task and relatively few subjects. Importantly, Ko and Myers draw attention to the difficulties of adapting the Whyline approach to applications written in several languages and those that cross machine boundaries. A new generation of languages and architectures is required in order to fully realize the potential of the "Why did..." and "Why didn't..." capabilities. I strongly recommend this paper to all computer scientists. Online Computing Reviews Service
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments