Will Snipes

It is a fact that a lot of software is written by people without a formal education in software engineering. As an example, material scientists often capture their knowledge in the form of simulation software that contains sophisticated algorithms representing complex physical concepts. Since software engineering is typically not a core skill of these scientists, there is a risk that their software becomes unmaintainable once it reaches a substantial size or structural complexity. This paper reports on a case study in which software engineers consulted magnetics researchers in refactoring their simulation software. This software had grown to 30 kloc of Java and was considered unmaintainable by the stakeholders of the research project. The case study describes the process of refactoring a system under the guidance of a software engineer with results supported by static analysis and software metrics. It shows how software engineers evaluated and selected refactorings to apply to the system using their expert judgment with input from static analysis tools and discusses the outcome of refactoring as evaluated by code owners and reported via static analysis metrics.

This paper describes a case study of using developer activity logs as indicators of a program comprehension effort by analyzing temporal sequences of developer actions (e.g., navigation and edit actions). We analyze developer activity data spanning 109,065 events and 69 hours of work on a medium-sized industrial application. We examine potential correlations between different measures of developer activity, code change metrics and code smells to gain insight into questions that could direct future technical debt interest estimation. To gain more insights into the data, we follow our analysis with commit message analysis and a developer interview. Our results indicate that developer activity as an estimate of program comprehension effort is correlated with both change proneness and static metrics for code smells.

Past studies show that developers who navigate code in a structural manner complete tasks faster and more correctly than those whose behavior is more opportunistic. The goal of this work is to move professional developers towards more effective program comprehension and maintenance habits by providing an approach that fosters structural code navigation. To this end, we created a Visual Studio plugin called Prodet that integrates an always-on navigable visualization of the most contextually relevant portions of the call graph. We evaluated the effectiveness of our approach by deploying it in a six week field study with professional software developers. The study results show a statistically significant increase in developers' use of structural navigation after installing Prodet. The results also show that developers continuously used the filtered and navigable call graph over the three week period in which it was deployed in production. These results indicate the maturity and value of our approach to increase developers' effectiveness in a practical and professional environment.

Evaluating technical debt related to code structure at a fine-grained level of detail is feasible using static code metrics to identify troublesome areas of a software code base. However, estimating the interest payments at a similar level of detail is a manual process relying on developers to submit their estimates as they encounter instances of technical debt. We propose a framework that continuously estimates interest payments using code comprehension metrics produced by a tool that monitors developer activities in the Integrated Development Environment. We describe the framework and demonstrate how it is used to evaluate the presence of technical debt and interest payments accumulated for code in an industrial software product.

Software engineering researchers develop great techniques consisting of practices and tools that improve efficiency and quality of software development. Prior work evaluates developers' use of techniques such as Test-Driven-Development and refactoring by measuring actions in the development environment. What we still lack is a method to communicate effectively and motivate developers to adopt best practices and tools. This work proposes a game-like system to motivate adoption while continuously measuring developers' use of more efficient development techniques.

Making a decision about whether to fix or defer fixing a defect is important to software projects. Deferring defects accumulates a technical debt that burdens the software team and customer with a less than optimal solution. The decision to defer fixing a defect is made by Software Change Control Boards (CCBs) based on a set of decision factors. In this paper, we evaluated the set of decision factors used by two CCBs at ABB in the context of technical debt management The aim was to determine how a model of cost and benefits of incurring technical debt could be part of the CCB decision process. We identified the cost categories and decision factors for fixing and deferring defects as a result of interviews with CCB members. We found that the decision factors could incorporate the financial aspects when using the technical debt metaphor. We identify opportunities for further research to integrate technical debt concepts with the decision factors towards better long term outcomes.

Commercial software development teams have limited time available to focus on improvements to their software. These teams need a way to quickly identify areas of the source code that would benefit from improvement, as well as quantifiable data to defend the selected improvements to management. Past research has shown that mining configuration management systems for change information can be useful in determining faulty areas of the code. We present a tool named Code Hot Spot, which mines change records out of Microsoft's TFS configuration management system and creates a report of hot spots. Hot spots are contiguous areas of the code that have higher values of metrics that are indicators of faulty code. We present a study where we use this tool to study projects at ABB to determine areas that need improvement. The resulting data have been used to prioritize areas for additional code reviews and unit testing, as well as identifying change prone areas in need of refactoring.