Programmers who are blind use a screen reader to speak source code one word at a time, as though the code were text. For example, "float f = 5.23;" can be read as "float f equals five point two three semicolon". This process of reading is in stark contrast to sighted programmers, who skim source code rapidly with their eyes. At present, it is not known whether the difference in these processes has effects on the program comprehension gained from reading code. These effects are important because they could reduce both the usefulness of accessibility tools and the generalizability of software engineering studies to persons with low vision. Furthermore, a lack of knowledge about blind programmers contributes to a bias against employing blind programmers. Employers are unfamiliar with the idea of a blind programmer and as a result may feel unsure about hiring one.

Blind programmers use a screen reader to read code aloud. Screen readers force blind programmers to read code sequentially one line at a time. In contrast, sighted programmers are able to skim visually to the most important code areas, assisted by syntax highlighting. However, there is a place where there is a widely adopted approach to skimming a structured document: the web. Modern screen readers employ what is known as a virtual cursor to navigate structural information on webpages such as HTML heading tags. These tags can indicate different sections and subsections in the structure of a page. We harness the existing familiarity of blind computer users with this interface in our approach which we call AudioHighlight. AudioHighlight renders the code inside a web view, either as part of the Eclipse IDE or as a web service. It places HTML heading tags on the structural elements of a source file such as classes, functions and control flow statements. We compare AudioHighlight to the state of the art in code skimming represented by a previous code skimming approach called StructJumper. We also compare to the state of practice in reading code on the web as represented by GitHub. We found that AudioHighlight increased the quality and speed of code comprehension as compared to both approaches.

This paper targets the problem of speech act detection in conversations about bug repair. We conduct a ``Wizard of Oz'' experiment with 30 professional programmers, in which the programmers fix bugs for two hours, and use a simulated virtual assistant for help. Then, we use an open coding manual annotation procedure to identify the speech act types in the conversations. Finally, we train and evaluate a supervised learning algorithm to automatically detect the speech act types in the conversations. In 30 two-hour conversations, we made 2459 annotations and uncovered 26 speech act types. Our automated detection achieved 69% precision and 50% recall. The key application of this work is to advance the state of the art for virtual assistants in software engineering. Virtual assistant technology is growing rapidly, though applications in software engineering are behind those in other areas, largely due to a lack of relevant data and experiments. This paper targets this problem in the area of developer Q/A conversations about bug repair.

Programmers who are blind use a screen reader to speak source code one word at a time, as though the code were text. This process of reading is in stark contrast to sighted programmers, who skim source code rapidly with their eyes. At present, it is not known whether the difference in these processes has effects on the program comprehension gained from reading code. These effects are important because they could reduce both the usefulness of accessibility tools and the generalizability of software engineering studies to persons with low vision. In this paper, we present an empirical study comparing the program comprehension of blind and sighted programmers. We found that both blind and sighted programmers prioritize reading method signatures over other areas of code. Both groups obtained an equal and high degree of comprehension, despite the different reading processes.

Programmers need documentation to comprehend software, but they often lack the time to write it. Thus, programmers must prioritize their documentation effort to ensure that sections of code important to program comprehension are thoroughly explained. In this paper, we explore the possibility of automatically prioritizing documentation effort. We performed two user studies to evaluate the effectiveness of static source code attributes and textual analysis of source code towards prioritizing documentation effort. The first study used open-source API Libraries while the second study was conducted using closed-source industrial software from ABB. Our findings suggest that static source code attributes are poor predictors of documentation effort priority, whereas textual analysis of source code consistently performed well as a predictor of documentation effort priority.

User stories are descriptions of functionality that a software user needs. They play an important role in determining which software requirements and bug fixes should be handled and in what order. Developers elicit user stories through meetings with customers. But user story elicitation is complex, and involves many passes to accommodate shifting and unclear customer needs. The result is that developers must take detailed notes during meetings or risk missing important information. Ideally, developers would be freed of the need to take notes themselves, and instead speak naturally with their customers. This paper is a step towards that ideal. We present a technique for automatically extracting information relevant to user stories from recorded conversations between customers and developers. We perform a qualitative study to demonstrate that user story information exists in these conversations in a sufficient quantity to extract automatically. From this, we found that roughly 10.2% of these conversations contained user story information. Then, we test our technique in a quantitative study to determine the degree to which our technique can extract user story information. In our experiment, our process obtained about 70.8% precision and 18.3% recall on the information.

When learning to use an Application Programming Interface (API), programmers need to understand the inputs and outputs (I/O) of the API functions. Current documentation tools automatically document the static information of I/O, such as parameter types and names. What is missing from these tools is dynamic information, such as I/O examples-actual valid values of inputs that produce certain outputs. In this paper, we demonstrate Docio, a prototype toolset we built to generate I/O examples. Docio logs I/O values when API functions are executed, for example in running test suites. Then, Docio puts I/O values into API documents as I/O examples. Docio has three programs: 1) funcWatch, which collects I/O values when API developers run test suites, 2) ioSelect, which selects one I/O example from a set of I/O values, and 3) ioPresent, which embeds the I/O examples into documents. In a preliminary evaluation, we used Docio to generate four hundred I/O examples for three C libraries: ffmpeg, libssh, and protobuf-c. Docio is open-source and available at: http://www3.nd.edu/~sjiang1/docio/.

Commit messages are a valuable resource in comprehension of software evolution, since they provide a record of changes such as feature additions and bug repairs. Unfortunately, programmers often neglect to write good commit messages. Different techniques have been proposed to help programmers by automatically writing these messages. These techniques are effective at describing what changed, but are often verbose and lack context for understanding the rationale behind a change. In contrast, humans write messages that are short and summarize the high level rationale. In this paper, we adapt Neural Machine Translation (NMT) to automatically "translate" diffs into commit messages. We trained an NMT algorithm using a corpus of diffs and human-written commit messages from the top 1k Github projects. We designed a filter to help ensure that we only trained the algorithm on higher-quality commit messages. Our evaluation uncovered a pattern in which the messages we generate tend to be either very high or very low quality. Therefore, we created a quality-assurance filter to detect cases in which we are unable to produce good messages, and return a warning instead.

We present a case study of feature location in industry. We study two off-the-shelf feature location algorithms for use as input to a software cost estimator. The feature location algorithms that we studied map program requirements to one or more function points. The cost estimator product, which is the industrial context in which we study feature location, transforms the list of function points into an estimate of the resources necessary to implement that requirement. We chose the feature location algorithms because they are simple to explain, deploy and maintain as a project evolves and personnel rotate on and off. We tested both feature location algorithms against a large software system with a development lifespan of over 20 years. We compared both algorithms by surveying our industrial partner about the accuracy of the list of function points produced by each algorithm. To provide further evidence, we compared both algorithms against an open source benchmarking dataset. Finally, we discuss the requirements of the industrial environment and the ways in which it differs from the academic environment. Our industrial partner elected to use Lucene combined with the PageRank algorithm as their feature location algorithm because it balanced accuracy with simplicity.

Abstract A key problem during copy–paste source code reuse is that, to reuse even a small section of code from a program as opposed to an API, a programmer must include a huge amount of additional source code from elsewhere in the same program. This additional code is notoriously large and complex, and portions can only be identified at runtime. In this paper, we propose execution record/replay as a solution to this problem. We describe a novel reuse technique that allows programmers to reuse functions from a C or C++ program, by recording the execution of the program and selectively modifying how its functions are replayed. We have implemented our technique and evaluated it in an empirical study in which eight programmers used our tool to complete four tasks over four hours each. The participants found our technique to be easier than manually reusing the code as part of their project. We also found that the resulting code was smaller and less complex than it would have been had the participants manually reused the code. Copyright © 2016 John Wiley & Sons, Ltd.