Emerson R. Murphy-Hill

How We Refactor, and How We Know It

Refactoring is widely practiced by developers, and considerable research and development effort has been invested in refactoring tools. However, little has been reported about the adoption of refactoring tools, and many assumptions about refactoring practice have little empirical support. In this paper, we examine refactoring tool usage and evaluate some of the assumptions made by other researchers. To measure tool usage, we randomly sampled code changes from four Eclipse and eight Mylyn developers and ascertained, for each refactoring, if it was performed manually or with tool support. We found that refactoring tools are seldom used: 11 percent by Eclipse developers and 9 percent by Mylyn developers. To understand refactoring practice at large, we drew from a variety of data sets spanning more than 39,000 developers, 240,000 tool-assisted refactorings, 2,500 developer hours, and 12,000 version control commits. Using these data, we cast doubt on several previously stated assumptions about how programmers refactor, while validating others. Finally, we interviewed the Eclipse and Mylyn developers to help us understand why they did not use refactoring tools and to gather ideas for future research.

Why don't software developers use static analysis tools to find bugs?

Using static analysis tools for automating code inspections can be beneficial for software engineers. Such tools can make finding bugs, or software defects, faster and cheaper than manual inspections. Despite the benefits of using static analysis tools to find bugs, research suggests that these tools are underused. In this paper, we investigate why developers are not widely using static analysis tools and how current tools could potentially be improved. We conducted interviews with 20 developers and found that although all of our participants felt that use is beneficial, false positives and the way in which the warnings are presented, among other things, are barriers to use. We discuss several implications of these results, such as the need for an interactive mechanism to help developers fix defects.

Breaking the barriers to successful refactoring: observations and tools for extract method

Refactoring is the process of changing the structure of code without changing its behavior. Refactoring can be semi-automated with tools, which should make it easier for programmers to refactor quickly and correctly. However, we have observed that many tools do a poor job of communicating errors triggered by the refactoring process and that programmers using them sometimes refactor slowly, conservatively, and incorrectly. In this paper we characterize problems with current refactoring tools, demonstrate three new tools to assist in refactoring, and report on a user study that compares these new tools against existing tools. The results of the study show that speed, accuracy, and user satisfaction can be significantly increased. From the new tools we induce a set of usability recommendations that we hope will help inspire a new generation of programmer-friendly refactoring tools.

Refactoring Tools: Fitness for Purpose

Refactoring tools can improve the speed and accuracy with which we create and maintain software — but only if they are used. In practice, tools are not used as much as they could be; this seems to be because they do not align with the refactoring strategy preferred by the majority of programmers: floss refactoring. We propose five principles that characterize successful floss refactoring tools — principles that can help programmers to choose the most appropriate refactoring tools and also help toolsmiths to design more usable tools.

An interactive ambient visualization for code smells

Code smells are characteristics of software that indicate that code may have a design problem. Code smells have been proposed as a way for programmers to recognize the need for restructuring their software. Because code smells can go unnoticed while programmers are working, tools called smell detectors have been developed to alert programmers to the presence of smells in their code, and to help them understand the cause of those smells. In this paper, we propose a novel smell detector called Stench Blossom that provides an interactive ambient visualization designed to first give programmers a quick, high-level overview of the smells in their code, and then, if they wish, to help in understanding the sources of those code smells. We also describe a laboratory experiment with 12 programmers that tests several hypotheses about our tool. Our findings suggest that programmers can use our tool effectively to identify smells and to make refactoring judgements. This is partly because the tool serves as a memory aid, and partly because it is more reliable and easier to use than heuristics for analyzing smells.

Improving software developers' fluency by recommending development environment commands

Software developers interact with the development environments they use by issuing commands that execute various programming tools, from source code formatters to build tools. However, developers often only use a small subset of the commands offered by modern development environments, reducing their overall development fluency. In this paper, we use several existing command recommender algorithms to suggest new commands to developers based on their existing command usage history, and also introduce several new algorithms. By running these algorithms on data submitted by several thousand Eclipse users, we describe two studies that explore the feasibility of automatically recommending commands to software developers. The results suggest that, while recommendation is more difficult in development environments than in other domains, it is still feasible to automatically recommend commands to developers based on their usage history, and that using patterns of past discovery is a useful way to do so.

Cowboys, ankle sprains, and keepers of quality: how is video game development different from software development?

Video games make up an important part of the software industry, yet the software engineering community rarely studies video games. This imbalance is a problem if video game development differs from general software development, as some game experts suggest. In this paper we describe a study with 14 interviewees and 364 survey respondents. The study elicited substantial differences between video game development and other software development. For example, in game development, “cowboy coders” are necessary to cope with the continuous interplay between creative desires and technical constraints. Consequently, game developers are hesitant to use automated testing because of these tests’ rapid obsolescence in the face of shifting creative desires of game designers. These differences between game and non-game development have implications for research, industry, and practice. For instance, as a starting point for impacting game development, researchers could create testing tools that enable game developers to create tests that assert flexible behavior with little up-front investment.

Is programming knowledge related to age? An exploration of stack overflow

Becoming an expert at programming is thought to take an estimated 10,000 hours of deliberate practice. But what happens after that? Do programming experts continue to develop, do they plateau, or is there a decline at some point? A diversity of opinion exists on this matter, but many seem to think that aging brings a decline in adoption and absorption of new programming knowledge. We develop several research questions on this theme, and draw on data from StackOverflow (SO) to address these questions. The goal of this research is to support career planning and staff development for programmers by identifying age-related trends in SO data. We observe that programmer reputation scores increase relative to age well into the 50s, that programmers in their 30s tend to focus on fewer areas relative to those younger or older in age, and that there is not a strong correlation between age and scores in specific knowledge areas.

Java generics adoption: how new features are introduced, championed, or ignored

Support for generic programming was added to the Java language in 2004, representing perhaps the most significant change to one of the most widely used programming languages today. Researchers and language designers anticipated this addition would relieve many long-standing problems plaguing developers, but surprisingly, no one has yet measured whether generics actually provide such relief. In this paper, we report on the first empirical investigation into how Java generics have been integrated into open source software by automatically mining the history of 20 popular open source Java programs, traversing more than 500 million lines of code in the process. We evaluate five hypotheses, each based on assertions made by prior researchers, about how Java developers use generics. For example, our results suggest that generics do not significantly reduce the number of type casts and that generics are usually adopted by a single champion in a project, rather than all committers.

Improving developer participation rates in surveys

Doing high quality research about the human side of software engineering necessitates the participation of real software developers in studies, but getting high levels of participation is a challenge for software engineering researchers. In this paper, we discuss several factors that software engineering researchers can use when recruiting participants, drawn from a combination of general research on survey design, research on persuasion, and our experience in conducting surveys. We study these factors by performing post-hoc analysis on several previously conducted surveys. Our results provide insight into the factors associated with increased response rates, which are neither wholly composed of factors associated strictly with persuasion research, nor those of conventional wisdom in software engineering.