Are automated debugging techniques actually helping programmers?

By Chris Parnin, Alessandro Orso. 2011

642 citations recorded by the source corpus.

Subfields: Information Systems, Software

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Information Systems

1. Earl T. Barr
2. Georgios Gousios
3. Premkumar T. Devanbu
4. Claire Le Goues
5. Charles Sutton
6. David Lo
7. Miltiadis Allamanis
8. Sebastian Proksch

In Software

1. Earl T. Barr
2. Claire Le Goues
3. Georgios Gousios
4. David Lo
5. Yuriy Brun
6. Westley Weimer
7. Shin Yoo
8. Edward K. Smith

Citations in the corpus

• Improving Robot Controller Transparency Through Autonomous Policy Explanation (2017, background): “These approaches maintain the critical assumption that identifying a faulty statement is sufficient to allow a developer to detect, understand, and correct the issue introduced by the error [31].”
• Decoding the Representation of Code in the Brain: An fMRI Study of Code Review and Expertise (2017, background): “As a concrete example, a number of fault localization approaches present their output as ranked lists, a form that humans dislike in this context [55].”
• Assessing the Type Annotation Burden (2018, background): “Parnin and Orso’s work on automatic suggestions in fault isolation [34] showed that when a tool makes multiple suggestions to a developer, only the first suggestion is likely to be used.”
• A Survey on Software Fault Localization (2016, background): “Last but not least, it is important to realize that software fault localization techniques should not be evaluated only in terms of effectiveness as described above [285].”
• Ask the Mutants: Mutating Faulty Programs for Fault Localization (2014, background): “However, it has also been criticized for their impractical accuracy and the unrealistic usage model that is the linear inspection of the ranking [22].”
• Type4Py: Practical Deep Similarity Learning-Based Type Inference for Python (2021, background): “As stated earlier, developers are more likely to use the first suggestion by a tool [48].”
• Metallaxis‐FL: mutation‐based fault localization (2015, background): “Parin and Orso [39] conducted a small case study investigating this issue.”
• Practitioners' expectations on automated fault localization (2016, positive): “Parnin and Orso [31] investigated the usability of a spectrumbased fault localization technique named Tarantula [17].”
• A theoretical analysis of the risk evaluation formulas for spectrum-based fault localization (2013, methodology): “Therefore, though this assumption is not normally satis.ed in practice, it has actually been accepted by the SBFL community, because it provides a fair comparison among different SBFL techniques [Parnin and Orso 2011].”
• The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs (2015, background): “considering if perfect fault location information would be of use to developers [78].”
• Is the cure worse than the disease? overfitting in automated program repair (2015, background): “While the human judgment is a criterion not used by the repair tools for patch construction, it is fundamentally different from the correctness criterion we use in our evaluation, as it is often difficult for humans to spot bugs even when told exactly where to look for them [45].”
• LineVul: A Transformer-based Line-Level Vulnerability Prediction (2022, background): “The intuition is that security analysts may ignore line-level recommendations if they do not appear in the top-10 ranking, similar to any recommendation systems [37].”