Developers ask reachability questions

LaToza, Thomas D.; Myers, Brad A.

doi:10.1145/1806799.1806829

Cited by 113 publications

(80 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…During this extensive exploration process, Jim becomes disoriented, and forgets which source code locations he has investigated. Furthermore, Jim must continually identify NavClus is designed to help Jim both in coping with disorientation during exploration [1] and in identifying new source locations to explore [2]. To reduce disorientation, NavClus incrementally displays where the developer has visited.…”

Section: Example Use Casementioning

confidence: 99%

“…Each subject will be asked to numerically evaluate NavClus (1)(2)(3)(4)(5) and to describe about any past experience dealing with diagramming tools and experience with NavClus.…”

Section: Evaluation Planmentioning

confidence: 99%

“…First, as the number of visited locations increases, developers may struggle to recall where they have already visited, and thus become disoriented in the code base [1]. Second, developers generally cannot remember the detailed structure of complex code bases, and must actively explore to understand how to modify the system, a task that can be quite challenging [2].…”

Section: Introductionmentioning

confidence: 99%

“…This tool addresses the second problem [2] by suggesting unvisited locations for further exploration. It is based on our previous work on the technique that mines developer interaction traces, identifies the developer's working context, and uses this information to recommend other relevant source locations [6].…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

NavClus: A graphical recommender for assisting code exploration

Lee

Kang

Staats

2013

2013 35th International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

Abstract-Recently, several graphical tools have been proposed to help developers avoid becoming disoriented when working with large software projects. These tools visualize the locations that developers have visited, allowing them to quickly recall where they have already visited. However, developers also spend a significant amount of time exploring source locations to visit, which is a task that is not currently supported by existing tools. In this work, we propose a graphical code recommender NavClus, which helps developers find relevant, unexplored source locations to visit. NavClus operates by mining a developer's daily interaction traces, comparing the developer's current working context with previously seen contexts, and then predicting relevant source locations to visit. These locations are displayed graphically along with the already explored locations in a class diagram. As a result, with NavClus developers can quickly find, reach, and focus on source locations relevant to their working contexts.

show abstract

Section: Example Use Casementioning

confidence: 99%

“…Each subject will be asked to numerically evaluate NavClus (1)(2)(3)(4)(5) and to describe about any past experience dealing with diagramming tools and experience with NavClus.…”

Section: Evaluation Planmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

NavClus: A graphical recommender for assisting code exploration

Lee

Kang

Staats

2013

2013 35th International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

show abstract

“…Valgrind [139], which, among other purposes, is useful for debugging memory errors). They often must engage in complex reasoning about program structure and control-flow [140] to fully understand the problem.…”

Section: How Do Humans Fix Bugs?mentioning

confidence: 99%

Automatic Program Repair Using Genetic Programming

Goues¹

View full text Add to dashboard Cite

Software quality is an urgent problem. There are so many bugs in industrial program source code that mature software projects are known to ship with both known and unknown bugs [1], and the number of outstanding defects typically exceeds the resources available to address them [2]. This has become a pressing economic problem whose costs in the United States can be measured in the billions of dollars annually [3].A dominant reason that software defects are so expensive is that fixing them remains a manual process. The process of identifying, triaging, reproducing, and localizing a particular bug, coupled with the task of understanding the underlying error, identifying a set of code changes that address it correctly, and then verifying those changes, costs both time [4] and money, and the cost of repairing a defect can increase by orders of magnitude as development progresses [5]. As a result, many defects, including critical security defects [6], remain unaddressed for long periods of time [7]. Moreover, humans are error-prone, and many human fixes are imperfect, in that they are either incorrect or lead to crashes, hangs, corruption, or security problems [8]. As a result, defect repair has become a major component of software maintenance, which in turn consumes up to 90% of the total lifecycle cost of a given piece of software [9].Although considerable research attention has been paid to supporting various aspects of the manual debugging process [10,11], and also to preempting or dynamically addressing particular classes of vulnerabilities, such as buffer overruns [12,13], there exist virtually no previous automated solutions that address the synthesis of patches for general bugs as they are reported in real-world software.The primary contribution of this dissertation is GenProg, one of the very first automatic solutions designed to help alleviate the manual bug repair burden by automatically and generically patching bugs in deployed and legacy software. GenProg uses a novel genetic programming algorithm, guided by test cases and domain-specific operators, to affect scalable, expressive, and high quality automated repair. We present experimental evidence to substantiate our claims that GenProg can repair multiple types of bugs in multiple types of programs, and that it can repair a large proportion of the bugs that human developers address in practice (that it is expressive); that it scales to real-world system sizes (that it is scalable); and that it produces repairs that are of sufficiently high quality. Over the course of this evaluation, we contribute new benchmark sets of real bugs in real open-source software and novel experimental frameworks for quantitatively evaluating an automated repair technique. We also contribute a novel characterization of i Chapter 0Abstract ii the automated repair search space, and provide analysis both of that space and of the performance and scaling behavior of our technique.General automated software repair was unheard of in 2009. In 2013, it has its own multi-paper s...

show abstract

Human-Centered Methods to Boost Productivity

Myers

LaToza

2019

Rethinking Productivity in Software Engineering

View full text Add to dashboard Cite

Since programming is a human activity, we can look to fields that have already developed methods to better understand the details of human interactions with technologies. In particular, the field of human-computer interaction (HCI) has dozens, if not hundreds, of methods that have been validated for answering a wide range of questions about human behaviors [4]. (And many of these methods, in turn, have been adapted from methods used in psychology, ethnography, sociology, etc.) For example, in our research, we have documented our use of at least ten different human-centered methods across all the phases of software development [11], almost all of which have impacts on programmer productivity. Why would one want to use these methods? Even though productivity may be hard to quantify, as discussed in many previous chapters of this book, it is indisputable that problems exist with the languages, APIs, and tools that programmers use, and we should strive to fix these problems. Further, there are more ways to understand productivity than just metrics. HCI methods can help better understand programmers' real requirements and problems, help design better ways to address those challenges, and then help evaluate whether the design actually works for programmers. Involving real programmers in these investigations reveals real data that makes it possible to identify and fix productivity bottlenecks.

show abstract

Developers ask reachability questions

Cited by 113 publications

References 23 publications

NavClus: A graphical recommender for assisting code exploration

NavClus: A graphical recommender for assisting code exploration

Automatic Program Repair Using Genetic Programming

Human-Centered Methods to Boost Productivity

Contact Info

Product

Resources

About