Debugging is notoriously difficult and extremely time consuming. Researchers have therefore invested a considerable amount of effort in developing automated techniques and tools for supporting various debugging tasks. Although potentially useful, most of these techniques have yet to demonstrate their practical effectiveness. One common limitation of existing approaches, for instance, is their reliance on a set of strong assumptions on how developers behave when debugging (e.g., the fact that examining a faulty statement in isolation is enough for a developer to understand and fix the corresponding bug). In more general terms, most existing techniques just focus on selecting subsets of potentially faulty statements and ranking them according to some criterion. By doing so, they ignore the fact that understanding the root cause of a failure typically involves complex activities, such as navigating program dependencies and rerunning the program with different inputs. The overall goal of this research is to investigate how developers use and benefit from automated debugging tools through a set of human studies. As a first step in this direction, we perform a preliminary study on a set of developers by providing them with an automated debugging tool and two tasks to be performed with and without the tool. Our results provide initial evidence that several assumptions made by automated debugging techniques do not hold in practice. Through an analysis of the results, we also provide insights on potential directions for future work in the area of automated debugging.

No abstract

No 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 more directly 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 developers?

Biases against women in the workplace have been documented in a variety of studies. This paper presents the largest study to date on gender bias, where we compare acceptance rates of contributions from men versus women in an open source software community. Surprisingly, our results show that women's contributions tend to be accepted more often than men's. However, women's acceptance rates are higher only when they are not identifiable as women. Our results suggest that although women on GitHub may be more competent overall, bias against them exists nonetheless.

No abstract

Interrupted and blocked tasks are a daily reality for professional programmers. Unfortunately, the strategies programmers use to recover lost knowledge and rebuild context when resuming work have not yet been well studied. In this paper, we describe an exploratory analysis performed on 10,000 recorded sessions of 86 programmers and a survey of 414 programmers to understand the various strategies and coping mechanisms developers use to manage interrupted programming tasks. Based on the analysis, we propose a framework for understanding these strategies and suggest how task resumption might be better supported in future development tools. The results suggest that task resumption is a frequent and persistent problem for developers. For example, we find that only 10% of the sessions have programming activity resume in less than 1 min after an interruption, only 7% of the programming sessions involve no navigation to other locations prior to editing. We also found that programmers use multiple coping mechanisms to recover task context when resuming work.

Context: Security smells are coding patterns in source code that are indicative of security weaknesses. As infrastructure as code (IaC) scripts are used to provision cloud-based servers and systems at scale, security smells in IaC scripts could be used to enable malicious users to exploit vulnerabilities in the provisioned systems. Goal: The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code (IaC) scripts through an empirical study of security smells in IaC scripts. Methodology: We apply qualitative analysis with 3,339 IaC scripts to identify security smells for IaC scripts written in three languages: Ansible, Chef, and Puppet. We construct a static analysis tool called Security Linter for Infrastructure as Code scripts (SLIC) to automatically identify security smells in 61,097 scripts collected from 1,093 open source software repositories. We also submit bug reports for 1,500 randomly-selected smell occurrences identified from the 61,097 scripts. Results: We identify nine security smells for IaC scripts. By applying SLIC on 61,097 IaC scripts we identify 64,356 occurrences of security smells that included 9,092 hard-coded passwords. We observe agreement for 130 of the responded 187 bug reports, which suggests the relevance of security smells for IaC scripts amongst practitioners. Conclusion: We observe security smells to be prevalent in IaC scripts. We recommend practitioners to rigorously inspect the presence of the identified security smells in IaC scripts using (i) code review, and (ii) static analysis tools.