We provide an extensive overview of existing research in the field of software refactoring. This research is compared and discussed based on a number of different criteria: the refactoring activities that are supported, the specific techniques and formalisms that are used for supporting these activities, the types of software artifacts that are being refactored, the important issues that need to be taken into account when building refactoring tool support, and the effect of refactoring on the software process. A running example is used to explain and illustrate the main concepts.

/pdf/a-survey-of-software-refactoring-kgrdghit3u.pdf

A survey of software refactoring

Background: The accurate prediction of where faults are likely to occur in code can help direct test effort, reduce costs, and improve the quality of software. Objective: We investigate how the context of models, the independent variables used, and the modeling techniques applied influence the performance of fault prediction models. Method: We used a systematic literature review to identify 208 fault prediction studies published from January 2000 to December 2010. We synthesize the quantitative and qualitative results of 36 studies which report sufficient contextual and methodological information according to the criteria we develop and apply. Results: The models that perform well tend to be based on simple modeling techniques such as Naive Bayes or Logistic Regression. Combinations of independent variables have been used by models that perform well. Feature selection has been applied to these combinations when models are performing particularly well. Conclusion: The methodology used to build models seems to be influential to predictive performance. Although there are a set of fault prediction studies in which confidence is possible, more studies are needed that use a reliable methodology and which report their context, methodology, and performance comprehensively.

/pdf/a-systematic-literature-review-on-fault-prediction-50xbihfieh.pdf

A Systematic Literature Review on Fault Prediction Performance in Software Engineering

Machine learning offers a fantastically powerful toolkit for building useful complex prediction systems quickly. This paper argues it is dangerous to think of these quick wins as coming for free. Using the software engineering framework of technical debt, we find it is common to incur massive ongoing maintenance costs in real-world ML systems. We explore several ML-specific risk factors to account for in system design. These include boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, configuration issues, changes in the external world, and a variety of system-level anti-patterns.

/pdf/hidden-technical-debt-in-machine-learning-systems-2zp0mptk96.pdf

Hidden technical debt in Machine learning systems

During the past twenty-one years, over seventy-five papers and nine Ph.D. theses have been published on pointer analysis. Given the tomes of work on this topic one may wonder, “Haven'trdquo; we solved this problem yet?'' With input from many researchers in the field, this paper describes issues related to pointer analysis and remaining open problems.

https://www.cs.trinity.edu/~mlewis/CSCI3294-F01/Papers/p54-hind.pdf

Pointer analysis: haven't we solved this problem yet?

http://www.cs.rug.nl/paris/papers/JSS15.pdf

A systematic mapping study on technical debt and its management

Static analysis tools for software defect detection are becoming widely used in practice. However, there is little public information regarding the experimental evaluation of the accuracy and value of the warnings these tools report. In this paper, we discuss the warnings found by FindBugs, a static analysis tool that finds defects in Java programs. We discuss the kinds of warnings generated and the classification of warnings into false positives, trivial bugs and serious bugs. We also provide some insight into why static analysis tools often detect true but trivial bugs, and some information about defect warnings across the development lifetime of software release. We report data on the defect warnings in Sun's Java 6 JRE, in Sun's Glassfish JEE server, and in portions of Google's Java codebase. Finally, we report on some experiences from incorporating static analysis into the software development process at Google.

/pdf/evaluating-static-analysis-defect-warnings-on-production-47658tbdto.pdf

Evaluating static analysis defect warnings on production software

Static analysis tools report software defects that may or may not be detected by other verification methods. Two challenges complicating the adoption of these tools are spurious false positive warnings and legitimate warnings that are not acted on. This paper reports automated support to help address these challenges using logistic regression models that predict the foregoing types of warnings from signals in the warnings and implicated code. Because examining many potential signaling factors in large software development settings can be expensive, we use a screening methodology to quickly discard factors with low predictive power and cost-effectively build predictive models. Our empirical evaluation indicates that these models can achieve high accuracy in predicting accurate and actionable static analysis warnings, and suggests that the models are competitive with alternative models built without screening.

/pdf/predicting-accurate-and-actionable-static-analysis-warnings-2ytqaqsz9i.pdf

Predicting accurate and actionable static analysis warnings: an experimental approach

With a large and rapidly changing codebase, Google software engineers are constantly paying interest on various forms of technical debt. Google engineers also make efforts to pay down that debt, whether through special Fixit days, or via dedicated teams, variously known as janitors, cultivators, or demolition experts. We describe several related efforts to measure and pay down technical debt found in Google's BUILD files and associated dead code. We address debt found in dependency specifications, unbuildable targets, and unnecessary command line flags. These efforts often expose other forms of technical debt that must first be managed.

/pdf/searching-for-build-debt-experiences-managing-technical-debt-13rh64lape.pdf

Searching for build debt: experiences managing technical debt at Google

This poster will present our experiences using FindBugs in production software development environments, including both open source efforts and Google's internal code base. We summarize the defects found, describe the issue of real but trivial defects, and discuss the integration of FindBugs into Google's Mondrian code review system.

/pdf/using-findbugs-on-production-software-1rk46bzzso.pdf

Using FindBugs on production software

Restructuring software to improve its design can lower software maintenance costs. One problem in carrying out such a restructuring is planning the new detailed design. The star diagram manipulable visualization can help a programmer redesign a program based on abstract data types. However, our measurements revealed that the view can be too large for a programmer to effectively assimilate. Also, design plans can be expressed only by restructuring, although our studies revealed that it is beneficial to preplan a restructuring. Finally, the tool user can build a star diagram for only a single data structure, although an abstract data type might actually have several components or have multiple instantiations.Exploiting basic properties of the star diagram can mitigate these problems. First, programmer-controlled elision can remove clutter from the star diagram view. Second, elision and annotation of star diagram components can mimic restructuring, thereby supporting the planning of a restructuring. Such support also allows for the planning of a non-restructuring maintenance task. Finally, to dynamically control what data structures are visualized, the tool user can union star diagrams.We built a star diagram planning tool for C programs, measured its elision capabilities, and performed a programmer study for the encapsulation of a widely-used data structure in a 28,000 line program. We found that the amount of elision can be substantial, but is not always adequate. In the study we found that each programming team successfully planned their restructuring in rather different, unanticipated ways.

J. David Morgenthaler

Papers

Evaluating static analysis defect warnings on production software

Predicting accurate and actionable static analysis warnings: an experimental approach

Searching for build debt: experiences managing technical debt at Google

Using FindBugs on production software

Tool support for planning the restructuring of data abstractions in large systems