Why Don't People Use Refactoring Tools?

Tools that perform refactoring are currently under-utilized by programmers. As more advanced refactoring tools are designed, a great chasm widens between how the tools must be used and how programmers want to use them. In this position paper, we characterize the dominant process of refactoring, demonstrate that many research tools do not support this process, and initiate a call to action for designers of future refactoring tools. 1. Refactoring Tools are Underutilized Since the original Refactoring Browser [11], programming environments have seen a remarkable integration of tools that perform semi-automatic refactoring. Programmers have their choice of refactoring tools in most mainstream languages such as Java and C#. However, we believe that people just aren’t using refactoring tools as much as they could. During a controlled experiment, we asked 16 object-oriented programming students whether they had used refactoring tools – only two said they had, reporting using them only 20% and 60% of the time [7]. Of the 31 users of Eclipse 3.2 on Portland State University computers in the last 9 months, only 2 users logged any refactoring activity. In a survey we conducted at the Agile Open Northwest 2007 conference, 112 people self-reported on their use of refactoring tools. When available, they chose to use refactoring tools 68% of the time when tools were available, an estimate which is likely optimistically high. Murphy and colleagues’ data on Eclipse usage characterizes 41 programmers who were early tool adopters, and who used Eclipse for a significant amount of Java programming [6]. According to this data, over a mean period of about 66 hours per programmer, the median number of different refactoring tools used was just 4, with Rename and Move as the only refactorings practiced by the majority of subjects. While it is difficult to tell when people are using refactoring tools and when they could be using refactoring tools, this second hand evidence leads us to believe that refactoring tools are currently not used as much as they could be. 2. When do Programmers Refactor? We believe that explaining when programmers refactor also explains why programmers don’t use refactoring tools, especially tools produced by researchers. There are two different occasions when programmers refactor. The first kind occurs interweaved with normal program development, arising whenever and wherever design problems arise. For example, if a programmer introduces (or is about to introduce) duplication when adding a feature, then the programmer removes that duplication. Fowler originally argued strongly for this kind of refactoring [1], and more recently, Hayashi and colleagues [3] and Parnin and Gorg [8] stated they believed this was a common refactoring process. This kind of refactoring, done frequently to maintain healthy software, we shall call floss refactoring. The other kind of refactoring occurs when time is set aside. For example, a programmer may want to remove as much duplication as possible from an existing program. This sort of refactoring has been described by Kataoka and colleages [4], Pizka [9], and Borquin and Keller [1]. This kind of refactoring, done after software has become unhealthy, we shall call root canal refactoring. Floss refactoring appears to be more effective, currently more widely used, and likely to be more widely used in the future. Both Pizka [9] and Borquin and Keller [1] note distinct negative consequences when performing root canal refactoring. Over the history of 3 large open-source projects, Weisgerber and Diehl were surprised to find that development contained no days of only refactorings [13]; if a day contained only refactorings, it would have indicated root canal refactoring was taking place. Likewise, Eclipse usage data from Murphy and colleagues [6] show that on only one occasion out of thousands did a programmer perform only refactoring iterations between version control commits. Furthermore, because floss refactoring is a central part of Agile methodologies, as more programmers become Agile, we expect more programmers to adopt floss refactoring. 3. Tool Support for Floss Refactoring Even though floss refactoring appears to be a more popular strategy than root canal refactoring, many (if not most) tools for refactoring described in the literature are built for root canal usage. Smell detectors, fully automated refactoring tools, and refactoring scripts are examples of refactoring tools are typically built for root canal refactoring. For instance, jCosmo takes a significant amount of time and reports system-wide smells [12], making it inappropriate for floss refactoring. Guru restructures an entire inheritance hierarchy without regard to what a programmer is having trouble modifying or understanding [5], making this tool unsuitable to floss refactoring as well. Refactoring Browser scripts [10] may be too viscous for a programmer to use to perform an impromptu restructuring during floss refactoring. While we are only able to point out a few examples due to space constraints, we believe that the majority of tools described in the literature are designed for root canal refactoring. Some exceptions do exist, such as Hayashi and colleagues’ tool, which suggests refactoring candidates based on programmers’ copy and paste behavior [3].