Much of what we know about how programmers refactor in the wild is based on studies that examine ... more Much of what we know about how programmers refactor in the wild is based on studies that examine just a few software projects. Researchers have rarely taken the time to replicate these studies in other contexts or to examine the assumptions on which they are based. To help put refactoring research on a sound scientific basis, we draw conclusions using four data sets spanning more than 13 000 developers, 240 000 tool-assisted refactorings, 2500 developer hours, and 3400 version control commits. Using these data, we cast doubt on several previously stated assumptions about how programmers refactor, while validating others. For example, we find that programmers frequently do not indicate refactoring activity in commit logs, which contradicts assumptions made by several previous researchers. In contrast, we were able to confirm the assumption that programmers do frequently intersperse refactoring with other program changes. By confirming assumptions and replicating studies made by other researchers, we can have greater confidence that those researchers' conclusions are generalizable.
Support for generic programming was added to the Java language in 2004, representing perhaps the ... more Support for generic programming was added to the Java language in 2004, representing perhaps the most significant change to one of the most widely used programming languages today. Researchers and language designers anticipated this addition would relieve many long-standing problems plaguing developers, but surprisingly, no one has yet measured how generics have been adopted and used in practice. In this paper, we report on the first empirical investigation into how Java generics have been integrated into open source software by automatically mining the history of 40 popular open source Java programs, traversing more than 650 million lines of code in the process. We evaluate five hypotheses and research questions about how Java developers use generics. For example, our results suggest that generics sometimes reduce the number of type casts and that generics are usually adopted by a single champion in a project, rather than all committers. We also offer insights into why some features may be adopted sooner and others features may be held back.
14th IEEE International Conference on Program Comprehension (ICPC'06), 2000
Consequently, developers spend significant effort pursuing recovery of their context. By context,... more Consequently, developers spend significant effort pursuing recovery of their context. By context, we focus on the classes and methods within the code that are relevant to a specific bug being fixed or enhancement made. Context is reified by a program in terms of a set of presentations (windows a containing source code, command executions, and data files); however, it is not enough to save the latest context. Even when working on a single task, programmers flip between contexts as they extend their understanding, and when they decide on a change, they may have to visit several contexts in order to address all possible ripple effects. Consequently, we would like to record a history of contexts and be able to retrieve them as demanded by the current task. We introduce a novel technique to obtain a context, consisting of a set of methods relevant for the current task, from a programmer's interactions with an IDE. Using this context, we demonstrate how to improve the ability of a programmer to recover the mental state associated with tasks and to facilitate the exploration of software through recommendation systems.
Proceedings of the 36th International Conference on Software Engineering - ICSE 2014, 2014
ABSTRACT Program comprehension is an important cognitive process that inherently eludes direct me... more ABSTRACT Program comprehension is an important cognitive process that inherently eludes direct measurement. Thus, researchers are struggling with providing suitable programming languages, tools, or coding conventions to support developers in their everyday work. In this paper, we explore whether functional magnetic resonance imaging (fMRI), which is well established in cognitive neuroscience, is feasible to soundly measure program comprehension. In a controlled experiment, we observed 17 participants inside an fMRI scanner while they were comprehending short source-code snippets, which we contrasted with locating syntax errors. We found a clear, distinct activation pattern of five brain regions, which are related to working memory, attention, and language processing---all processes that fit well to our understanding of program comprehension. Our results encourage us and, hopefully, other researchers to use fMRI in future studies to measure program comprehension and, in the long run, answer questions, such as: Can we predict whether someone will be an excellent programmer? How effective are new languages and tools for program understanding? How should we train programmers?
Proceedings of the 2nd Workshop on Refactoring Tools - WRT '08, 2008
Those of us who seek to build better refactoring tools need empirical data collected from real re... more Those of us who seek to build better refactoring tools need empirical data collected from real refactoring sessions. The literature reports on different methods for capturing this data, but little is known about how the method of data capture affects the quality of the results. This paper describes 4 methods for drawing conclusions about how programmers refactor, characterizes the assumptions made by each, and presents a family of experiments to test those assumptions. We hope that the results of the experiments will help future researchers choose a data-collection method appropriate to the question that they want to investigate.
2012 20th IEEE International Conference on Program Comprehension (ICPC), 2012
ABSTRACT Despite its vast capacity and associative powers, the human brain does not deal well wit... more ABSTRACT Despite its vast capacity and associative powers, the human brain does not deal well with interruptions. Particularly in situations where information density is high, such as during a programming task, recovering from an interruption requires extensive time and effort. Although modern program development environments have begun to recognize this problem, none of these tools take into account the brain's structure and limitations. In this paper, we present a conceptual framework for understanding the strengths and weaknesses of human memory, particularly with respect to it ability to deal with work interruptions. The framework explains empirical results obtained from experiments in which programmers were interrupted while working. Based on the framework, we discuss programmer information needs that development tools must satisfy and suggest several memory aids such tools could provide. We also describe our prototype implementation of these memory aids.
Task management is an essential skill for developers to manage the many responsibilities they are... more Task management is an essential skill for developers to manage the many responsibilities they are assigned during software development. Developers must be able to suspend and later resume work on a programming task in the event of an interruption or the need to switch to a different task. However, little tool support is available for developers needing to recall details relevant to an interrupted task. In this paper, we present a technique that assists developers in reconstructing the details of activities performed during development work. Our technique provides a timeline visualization of recent development sessions, significant events, shifts in attention, and summaries of activities performed during a period of time. From these visualizations, developers can recover a task context from the code elements used during a selected time range.
Proceedings of the 2008 international workshop on Mining software repositories - MSR '08, 2008
Software archives are one of the best sources available to researchers for understanding the soft... more Software archives are one of the best sources available to researchers for understanding the software development process. However, much detective work is still necessary in order to unravel the software development story. During this process, researchers must isolate changes and follow their trails over time. In support of this analysis, several research tools have provided different representations for connecting the many changes extracted from software archives. Most of these tools are based on textual analysis of source code and use line-based differencing between software versions. This approach limits the ability to process changes structurally resulting in less concise and comparable items. Adoption of structure-based approaches have been hampered by complex implementations and overly verbose change descriptions. We present a technique for expressing changes that is fine-grained but preserves some structural aspects. The structural information itself may not have changed, but instead provides a context for interpreting the change. This in turn, enables more relevant and concise descriptions in terms of software types and programming activities. We apply our technique to common challenges that researchers face, and then we discuss and compare our results with other techniques.
Proceedings of the 2006 international workshop on Mining software repositories - MSR '06, 2006
Revision history provides a rich source of information to improve the understanding of changes ma... more Revision history provides a rich source of information to improve the understanding of changes made to programs, but it yields only limited insight into how these changes occurred. We explore an additional source of information -program viewing and editing history -where all historical artifacts associated with the program are included. In particular, we suggest augmenting revision histories with the interaction history of programmers. Using this additional information source enables the development of several interesting applications including an influence-recommendation system and a task-mining system. We present some results from a case study in which interaction histories from professional programmers were obtained and analyzed.
Proceedings of the 2006 ACM symposium on Software visualization - SoftVis '06, 2006
In this paper we present an approach for using lightweight visualizations to inspect bad coding p... more In this paper we present an approach for using lightweight visualizations to inspect bad coding patterns. We demonstrate how our Visual Studio plugin assists developers in finding relevant methods to inspect.
2007 4th IEEE International Workshop on Visualizing Software for Understanding and Analysis, 2007
Success in software development dictates that the right information reaches the right people. In ... more Success in software development dictates that the right information reaches the right people. In the development process, information flows among developers, managers, and customers. The information is represented in a multitude of sources: customer requirements, application domains, product specifications, development processes, schedules, budgets, project status reports, and task priorities. Unfortunately, in the transmission of information, vital tidbits are filtered away, made inaccessible, or withheld from the stakeholders. Software visualization systems have traditionally focused on the complexities of the relations and detailed structure of the software artifacts. Recently, attention has been given to visualizing software artifacts from the perspective of supporting teams in coordinating efforts. In this paper, we describe the nature of this information source and provide design guidelines for developing ambient software visualizations in the workplace. In particular, we describe how developers can better understand more about project management, recall and perform tasks in their personal work flow, and coordinate project state that is continually changing.
Proceedings of the 5th international symposium on Software visualization - SOFTVIS '10, 2010
When software developers work with a program's source code, the structure of the source code ofte... more When software developers work with a program's source code, the structure of the source code often requires that they split their attention simultaneously across several documents and artifacts. Disruptions to programmers' concentration caused by overwhelmed capacity can then lead to programming errors and increases in the time to perform a task. We suggest the addition of peripheral interactive spaces to programming environments for supporting developers in maintaining their concentration. We introduce the novel concept of a CodePad, a peripheral, multi-touch enabled display that allows developers to engage with and manipulate multiple programming artifacts. We illustrate visualizations built for a CodePad that support multiple development scenarios and we describe how developers can coordinate the interaction and communication between a Code-Pad and a programming environment in personal and collaborative tasks. Additionally, we propose a design space for other visualization tools and detail our initial prototype.
2009 IEEE 17th International Conference on Program Comprehension, 2009
Developers must actively maintain plans and goals about their programming tasks. Unfortunately, m... more Developers must actively maintain plans and goals about their programming tasks. Unfortunately, much of this knowledge about tasks does not exist in a tangible form. Commonly, developers must recover the details of this knowledge after encountering an unanticipated interruption. In this paper, we present a technique for allowing developers to quickly reengage in a task after an interruption. A dashboard visualization of intermediate task knowledge is prepared from recent interactions and program executions and then displayed to assist in restoring task knowledge. Additionally, developers can annotate the artifacts with task sketches and prospective cues.
Much of what we know about how programmers refactor in the wild is based on studies that examine ... more Much of what we know about how programmers refactor in the wild is based on studies that examine just a few software projects. Researchers have rarely taken the time to replicate these studies in other contexts or to examine the assumptions on which they are based. To help put refactoring research on a sound scientific basis, we draw conclusions using four data sets spanning more than 13 000 developers, 240 000 tool-assisted refactorings, 2500 developer hours, and 3400 version control commits. Using these data, we cast doubt on several previously stated assumptions about how programmers refactor, while validating others. For example, we find that programmers frequently do not indicate refactoring activity in commit logs, which contradicts assumptions made by several previous researchers. In contrast, we were able to confirm the assumption that programmers do frequently intersperse refactoring with other program changes. By confirming assumptions and replicating studies made by other researchers, we can have greater confidence that those researchers' conclusions are generalizable.
Support for generic programming was added to the Java language in 2004, representing perhaps the ... more Support for generic programming was added to the Java language in 2004, representing perhaps the most significant change to one of the most widely used programming languages today. Researchers and language designers anticipated this addition would relieve many long-standing problems plaguing developers, but surprisingly, no one has yet measured how generics have been adopted and used in practice. In this paper, we report on the first empirical investigation into how Java generics have been integrated into open source software by automatically mining the history of 40 popular open source Java programs, traversing more than 650 million lines of code in the process. We evaluate five hypotheses and research questions about how Java developers use generics. For example, our results suggest that generics sometimes reduce the number of type casts and that generics are usually adopted by a single champion in a project, rather than all committers. We also offer insights into why some features may be adopted sooner and others features may be held back.
14th IEEE International Conference on Program Comprehension (ICPC'06), 2000
Consequently, developers spend significant effort pursuing recovery of their context. By context,... more Consequently, developers spend significant effort pursuing recovery of their context. By context, we focus on the classes and methods within the code that are relevant to a specific bug being fixed or enhancement made. Context is reified by a program in terms of a set of presentations (windows a containing source code, command executions, and data files); however, it is not enough to save the latest context. Even when working on a single task, programmers flip between contexts as they extend their understanding, and when they decide on a change, they may have to visit several contexts in order to address all possible ripple effects. Consequently, we would like to record a history of contexts and be able to retrieve them as demanded by the current task. We introduce a novel technique to obtain a context, consisting of a set of methods relevant for the current task, from a programmer's interactions with an IDE. Using this context, we demonstrate how to improve the ability of a programmer to recover the mental state associated with tasks and to facilitate the exploration of software through recommendation systems.
Proceedings of the 36th International Conference on Software Engineering - ICSE 2014, 2014
ABSTRACT Program comprehension is an important cognitive process that inherently eludes direct me... more ABSTRACT Program comprehension is an important cognitive process that inherently eludes direct measurement. Thus, researchers are struggling with providing suitable programming languages, tools, or coding conventions to support developers in their everyday work. In this paper, we explore whether functional magnetic resonance imaging (fMRI), which is well established in cognitive neuroscience, is feasible to soundly measure program comprehension. In a controlled experiment, we observed 17 participants inside an fMRI scanner while they were comprehending short source-code snippets, which we contrasted with locating syntax errors. We found a clear, distinct activation pattern of five brain regions, which are related to working memory, attention, and language processing---all processes that fit well to our understanding of program comprehension. Our results encourage us and, hopefully, other researchers to use fMRI in future studies to measure program comprehension and, in the long run, answer questions, such as: Can we predict whether someone will be an excellent programmer? How effective are new languages and tools for program understanding? How should we train programmers?
Proceedings of the 2nd Workshop on Refactoring Tools - WRT '08, 2008
Those of us who seek to build better refactoring tools need empirical data collected from real re... more Those of us who seek to build better refactoring tools need empirical data collected from real refactoring sessions. The literature reports on different methods for capturing this data, but little is known about how the method of data capture affects the quality of the results. This paper describes 4 methods for drawing conclusions about how programmers refactor, characterizes the assumptions made by each, and presents a family of experiments to test those assumptions. We hope that the results of the experiments will help future researchers choose a data-collection method appropriate to the question that they want to investigate.
2012 20th IEEE International Conference on Program Comprehension (ICPC), 2012
ABSTRACT Despite its vast capacity and associative powers, the human brain does not deal well wit... more ABSTRACT Despite its vast capacity and associative powers, the human brain does not deal well with interruptions. Particularly in situations where information density is high, such as during a programming task, recovering from an interruption requires extensive time and effort. Although modern program development environments have begun to recognize this problem, none of these tools take into account the brain's structure and limitations. In this paper, we present a conceptual framework for understanding the strengths and weaknesses of human memory, particularly with respect to it ability to deal with work interruptions. The framework explains empirical results obtained from experiments in which programmers were interrupted while working. Based on the framework, we discuss programmer information needs that development tools must satisfy and suggest several memory aids such tools could provide. We also describe our prototype implementation of these memory aids.
Task management is an essential skill for developers to manage the many responsibilities they are... more Task management is an essential skill for developers to manage the many responsibilities they are assigned during software development. Developers must be able to suspend and later resume work on a programming task in the event of an interruption or the need to switch to a different task. However, little tool support is available for developers needing to recall details relevant to an interrupted task. In this paper, we present a technique that assists developers in reconstructing the details of activities performed during development work. Our technique provides a timeline visualization of recent development sessions, significant events, shifts in attention, and summaries of activities performed during a period of time. From these visualizations, developers can recover a task context from the code elements used during a selected time range.
Proceedings of the 2008 international workshop on Mining software repositories - MSR '08, 2008
Software archives are one of the best sources available to researchers for understanding the soft... more Software archives are one of the best sources available to researchers for understanding the software development process. However, much detective work is still necessary in order to unravel the software development story. During this process, researchers must isolate changes and follow their trails over time. In support of this analysis, several research tools have provided different representations for connecting the many changes extracted from software archives. Most of these tools are based on textual analysis of source code and use line-based differencing between software versions. This approach limits the ability to process changes structurally resulting in less concise and comparable items. Adoption of structure-based approaches have been hampered by complex implementations and overly verbose change descriptions. We present a technique for expressing changes that is fine-grained but preserves some structural aspects. The structural information itself may not have changed, but instead provides a context for interpreting the change. This in turn, enables more relevant and concise descriptions in terms of software types and programming activities. We apply our technique to common challenges that researchers face, and then we discuss and compare our results with other techniques.
Proceedings of the 2006 international workshop on Mining software repositories - MSR '06, 2006
Revision history provides a rich source of information to improve the understanding of changes ma... more Revision history provides a rich source of information to improve the understanding of changes made to programs, but it yields only limited insight into how these changes occurred. We explore an additional source of information -program viewing and editing history -where all historical artifacts associated with the program are included. In particular, we suggest augmenting revision histories with the interaction history of programmers. Using this additional information source enables the development of several interesting applications including an influence-recommendation system and a task-mining system. We present some results from a case study in which interaction histories from professional programmers were obtained and analyzed.
Proceedings of the 2006 ACM symposium on Software visualization - SoftVis '06, 2006
In this paper we present an approach for using lightweight visualizations to inspect bad coding p... more In this paper we present an approach for using lightweight visualizations to inspect bad coding patterns. We demonstrate how our Visual Studio plugin assists developers in finding relevant methods to inspect.
2007 4th IEEE International Workshop on Visualizing Software for Understanding and Analysis, 2007
Success in software development dictates that the right information reaches the right people. In ... more Success in software development dictates that the right information reaches the right people. In the development process, information flows among developers, managers, and customers. The information is represented in a multitude of sources: customer requirements, application domains, product specifications, development processes, schedules, budgets, project status reports, and task priorities. Unfortunately, in the transmission of information, vital tidbits are filtered away, made inaccessible, or withheld from the stakeholders. Software visualization systems have traditionally focused on the complexities of the relations and detailed structure of the software artifacts. Recently, attention has been given to visualizing software artifacts from the perspective of supporting teams in coordinating efforts. In this paper, we describe the nature of this information source and provide design guidelines for developing ambient software visualizations in the workplace. In particular, we describe how developers can better understand more about project management, recall and perform tasks in their personal work flow, and coordinate project state that is continually changing.
Proceedings of the 5th international symposium on Software visualization - SOFTVIS '10, 2010
When software developers work with a program's source code, the structure of the source code ofte... more When software developers work with a program's source code, the structure of the source code often requires that they split their attention simultaneously across several documents and artifacts. Disruptions to programmers' concentration caused by overwhelmed capacity can then lead to programming errors and increases in the time to perform a task. We suggest the addition of peripheral interactive spaces to programming environments for supporting developers in maintaining their concentration. We introduce the novel concept of a CodePad, a peripheral, multi-touch enabled display that allows developers to engage with and manipulate multiple programming artifacts. We illustrate visualizations built for a CodePad that support multiple development scenarios and we describe how developers can coordinate the interaction and communication between a Code-Pad and a programming environment in personal and collaborative tasks. Additionally, we propose a design space for other visualization tools and detail our initial prototype.
2009 IEEE 17th International Conference on Program Comprehension, 2009
Developers must actively maintain plans and goals about their programming tasks. Unfortunately, m... more Developers must actively maintain plans and goals about their programming tasks. Unfortunately, much of this knowledge about tasks does not exist in a tangible form. Commonly, developers must recover the details of this knowledge after encountering an unanticipated interruption. In this paper, we present a technique for allowing developers to quickly reengage in a task after an interruption. A dashboard visualization of intermediate task knowledge is prepared from recent interactions and program executions and then displayed to assist in restoring task knowledge. Additionally, developers can annotate the artifacts with task sketches and prospective cues.
Uploads
Papers by C. Parnin