The whats and hows of programmers' foraging diets

One of the least studied areas of Information Foraging Theory is diet: the information foragers choose to seek. For example, do foragers choose solely based on cost, or do they stubbornly pursue certain diets regardless of cost? Do their debugging strategies vary with their diets? To investigate "what" and "how" questions like these for the domain of software debugging, we qualitatively analyzed 9 professional developers' foraging goals, goal patterns, and strategies. Participants spent 50% of their time foraging. Of their foraging, 58% fell into distinct dietary patterns—mostly in patterns not previously discussed in the literature. In general, programmers' foraging strategies leaned more heavily toward enrichment than we expected, but different strategies aligned with different goal types. These and our other findings help fill the gap as to what programmers' dietary goals are and how their strategies relate to those goals.This tech report is an extended version of publication [17]: It adds Appendix A to the end. © ACM, 2013. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in Proc. CHI, ACM (2013)Keywords: Information foraging theory, information diet, User/Machine Systems -- Human factors, Testing and Debugging, debugging strategie

Find Unique Usages: Helping Developers Understand Common Usages

When working in large and complex codebases, developers face challenges using \textit{Find Usages} to understand how to reuse classes and methods. To better understand these challenges, we conducted a small exploratory study with 4 participants. We found that developers often wasted time reading long lists of similar usages or prematurely focused on a single usage. Based on these findings, we hypothesized that clustering usages by the similarity of their surrounding context might enable developers to more rapidly understand how to use a function. To explore this idea, we designed and implemented \textit{Find Unique Usages}, which extracts usages, computes a diff between pairs of usages, generates similarity scores, and uses these scores to form usage clusters. To evaluate this approach, we conducted a controlled experiment with 12 participants. We found that developers with Find Unique Usages were significantly faster, completing their task in 35% less time

Exploring How Novice Programmers Pick Debugging Tactics When Debugging: A Student’s Perspective

Novice developers use a variety of debugging tactics to debug. However, how they select a tactic still remains unclear. Many studies in Software Engineering describe programmers using tactics like adding print statements, but only a few studies hint at factors such as knowledge and habits, social environment, and experience that may influence these decisions. To help us understand how novice programmers select debugging tactics, we turned to Information Foraging Theory (IFT) to analyze this decision-making process through the lens of a cost-benefit analysis. We conducted a qualitative study that explored how novice programmers describe their decision-making process when deciding which debugging tactics to use when debugging. We found that novice programmers use a variety of debugging tactics including testing code, searching for help, and taking notes on paper. Furthermore, we reported activities where novices leverage their past experiences, adapt to their task environments, and anticipate future risks and rewards to decide among a variety of tactics to pursue. From our results, we offer suggestions to educators to explicitly teach the value and costs of using certain tactics so that novice programmers may select the optimal tactic in any debugging situation. Furthermore, we suggest future research to explore novice debugging behaviors within non-computing environments to gain a holistic understanding of the debugging process

Information Foraging Theory as a Unifying Foundation for Software Engineering Research : Connecting the Dots

Empirical studies have shown that programmers spend up to one-third of their time navigating through code during debugging. Although researchers have conducted empirical studies to understand programmers’ navigation difficulties and developed tools to address those difficulties, the resulting findings tend to be loosely connected to each other. To address this gap, we propose using theory to “connect the dots” between software engineering (SE) research findings. Our theory of choice is Information Foraging Theory (IFT) which explains and predicts how people seek information in an environment. Thus, it is well-suited as a unifying foundation because navigating code is a fundamental aspect of software engineering. In this dissertation, we investigated IFT’s suitability as a unifying foundation for SE through a combination of tool building and empirical user studies of programmers debugging. Our contributions show how IFT can help to unify SE research via cross-cutting insights spanning multiple software engineering subdisciplines

Variations Foraging

Information Foraging Theory (IFT) has successfully explained how people seek information in various domains, in turn, informing the design of several tools and information-intensive environments. However, prior research has not explored foraging in the presence of several, very similar variants of the same artifact. Such variants are commonplace in several creative, exploratory tasks such as graphic design, writing and programming. In this thesis, we evaluate whether and how IFT applies to variants. Using empirical studies and computational models that predict programmers’ information foraging among variants, this thesis provides evidence for the applicability of IFT in variations situations and offers new insights for variations-support tools. Along the way, this thesis also demonstrates the benefits of computationally modeling: 1) the hierarchical organization of information environments, 2) variable costs of navigation in an information environment and 3) accounting for non-textual (graphical) information

Swarm Debugging: the Collective Intelligence on Interactive Debugging

One of the most important tasks in software maintenance is debugging. To start an interactive debugging session, developers usually set breakpoints in an integrated development environment and navigate through different paths in their debuggers. We started our work by asking what debugging information is useful to share among developers and study two pieces of information: breakpoints (and their locations) and sessions (debugging paths). To answer our question, we introduce the Swarm Debugging concept to frame the sharing of debugging information, the Swarm Debugging Infrastructure (SDI) with which practitioners and researchers can collect and share data about developers’ interactive debugging sessions, and the Swarm Debugging Global View (GV) to display debugging paths. Using the SDI, we conducted a large study with professional developers to understand how developers set breakpoints. Using the GV, we also analyzed professional developers in two studies and collected data about their debugging sessions. Our observations and the answers to our research questions suggest that sharing and visualizing debugging data can support debugging activities

Swarm Debugging: the Collective Intelligence on Interactive Debugging

One of the most important tasks in software maintenance is debugging. To start an interactive debugging session, developers usually set breakpoints in an integrated development environment and navigate through different paths in their debuggers. We started our work by asking what debugging information is useful to share among developers and study two pieces of information: breakpoints (and their locations) and sessions (debugging paths). To answer our question, we introduce the Swarm Debugging concept to frame the sharing of debugging information, the Swarm Debugging Infrastructure (SDI) with which practitioners and researchers can collect and share data about developers’ interactive debugging sessions, and the Swarm Debugging Global View (GV) to display debugging paths. Using the SDI, we conducted a large study with professional developers to understand how developers set breakpoints. Using the GV, we also analyzed professional developers in two studies and collected data about their debugging sessions. Our observations and the answers to our research questions suggest that sharing and visualizing debugging data can support debugging activities

Human-Centric Tools for Navigating Code

All software failures are fundamentally the fault of humansthe software\u27s design was flawed. The high cost of such failures ultimately results in developers having to design, implement, and test fixes, which all take considerable time and effort, and may result in more failures. As developers work on software maintenance tasks, they must navigate enormous codebases that may comprise millions of lines of code organized across thousands of modules. However, navigating code carries with it a plethora of problems for developers. In the hopes of addressing these navigation barriers, modern code editor and development environments provide a variety of features to aid in navigation; however, they are not without their limitations. Code navigations take many forms, and in this work I focus on three key types of code navigation in modern software development: navigating the working set, navigating among versions of code, and navigating the code structure. To address the challenges of navigating code, I designed three novel software development tools, one to enhance each type of navigation. First, I designed and implemented Patchworks, a code editor interface to support developers in navigating the working set. Patchworks aims to make these more efficient by providing a fixed grid of open code fragments that developers can quickly navigate. Second, I designed and implemented Yestercode, a code editor extension to support navigating among versions of code. Yestercode does so by providing a comparison view of the current code and a previous version of the same code. Third, I designed and implemented Wandercode, a code editor extension to enable developers to efficiently navigate the structure of their code. Wandercode aims to do so by providing a visualization of the code\u27s call graph overlayed on the code editor. My approach to designing these tools for more efficient code navigation was a human-centric onethat is, based on the needs of actual developers performing real software development tasks. Through user study evaluations, I found that these tools significantly improved developer productivity by reducing developers\u27 time spent navigating and mental effort during software maintenance tasks