Forrest Shull

Identification and management of technical debt

ContextThe technical debt metaphor describes the effect of immature artifacts on software maintenance that bring a short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Much research has been performed to propose mechanisms to identify debt and decide the most appropriate moment to pay it off. It is important to investigate the current state of the art in order to provide both researchers and practitioners with information that enables further research activities as well as technical debt management in practice. ObjectiveThis paper has the following goals: to characterize the types of technical debt, identify indicators that can be used to find technical debt, identify management strategies, understand the maturity level of each proposal, and identify what visualization techniques have been proposed to support technical debt identification and management activities. MethodA systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated. ResultsWe proposed an initial taxonomy of technical debt types, created a list of indicators that have been proposed to identify technical debt, identified the existing management strategies, and analyzed the current state of art on technical debt, identifying topics where new research efforts can be invested. ConclusionThe results of this mapping study can help to identify points that still require further investigation in technical debt research.

Practical considerations, challenges, and requirements of tool-support for managing technical debt

Developing a software product with a high level of quality that also meets budget and schedule is the main goal of any organization. This usually implies making tradeoffs among conflicting aspects like number of features to implement, user perceived quality, time-to-market, and the ability of the company to maintain and improve the system in a feasible way in the future (aka, managing Technical Debt (TD)). In this paper we present a fresh perspective on TD from a CMMI Maturity Level 5 company. Examples, practical considerations, and challenges in dealing with TD are presented along with ten requirements of a tool for managing TD.

Investigating technical debt folklore: shedding some light on technical debt opinion

We identified and organized a number of statements about technical debt (TD Folklore list) expressed by practitioners in online websites, blogs and published papers. We chose 14 statements and we evaluated them through two surveys (37 practitioners answered the questionnaires), ranking them by agreement and consensus. The statements most agreed with show that TD is an important factor in software project management and not simply another term for “bad code”. This study will help the research community in identifying folklore that can be translated into research questions to be investigated, thus targeting attempts to provide a scientific basis for TD management.

Technical Debt: Showing the Way for Better Transfer of Empirical Results

In this chapter, we discuss recent progress and opportunities in empirical software engineering by focusing on a particular technology, Technical Debt (TD), which ties together many recent developments in the field. Recent advances in TD research are providing empiricists the chance to make more sophisticated recommendations that have observable impact on practice.

Building Theories from Multiple Evidence Sources

As emphasized in other chapters of this book, useful results in empirical software engineering require a variety of data to be collected through different studies - focusing on a single context or single metric rarely tells a useful story. But, in each study, the requirements of the local context are liable to impose different con- straints on study design, the metrics to be collected, and other factors. Thus, even when all the studies focus on the same phenomenon (say, software quality), such studies can validly collect a number of different measures that are not at all com- patible (say, number of defects required to be fixed during development, number of problem reports received from the customer, total amount of effort that needed to be spent on rework). Can anything be done to build a useful body of knowledge from these disparate pieces? This chapter addresses strategies that have been applied to date to draw conclu- sions from across such varied but valid data sets. Key approaches are compared and the data to which they are best suited are identified. Our analysis together with associated lessons learned provide decision support for readers interested in choos- ing and using such approaches to build up useful theories.

Exploring language support for immutability

Programming languages can restrict state change by preventing it entirely (immutability) or by restricting which clients may modify state (read-only restrictions). The benefits of immutability and read-only restrictions in software structures have been long-argued by practicing software engineers, researchers, and programming language designers. However, there are many proposals for language mechanisms for restricting state change, with a remarkable diversity of techniques and goals, and there is little empirical data regarding what practicing software engineers want in their tools and what would benefit them. We systematized the large collection of techniques used by programming languages to help programmers prevent undesired changes in state. We interviewed expert software engineers to discover their expectations and requirements, and found that important requirements, such as expressing immutability constraints, were not reflected in features available in the languages participants used. The interview results informed our design of a new language extension for specifying immutability in Java. Through an iterative, participatory design process, we created a tool that reflects requirements from both our interviews and the research literature.

Are delayed issues harder to resolve? Revisiting cost-to-fix of defects throughout the lifecycle

Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner. This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006–2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. This paper documents the above study and explores reasons for this mismatch between this common rule of thumb and empirical data. In summary, DIE is not some constant across all projects. Rather, DIE might be an historical relic that occurs intermittently only in certain kinds of projects. This is a significant result since it predicts that new development processes that promise to faster retire more issues will not have a guaranteed return on investment (depending on the context where applied), and that a long-held truth in software engineering should not be considered a global truism.

The Computational Research and Engineering Acquisition Tools and Environments (CREATE) Program, Part 2

Physics-based high-performance computing (HPC) engineering software applications are proving to highly effective for the development of complex innovative products such as automobiles, airplanes, and microprocessors. Over the next year and a half, CiSE will feature three issues describing the US Department of Defense (DoD) High Performance Computing Modernization Program (HPCMP) Computational Research and Engineering Acquisition Tools and Environments (CREATE) program. CREATE was launched in 2006 to develop and deploy a set of multiphysics HPC software applications to help the DoD acquisition community (government and industry) develop innovative military air vehicle, naval vessel, and radio frequency antenna systems.

The True Cost of Mobility

IEEE Software Editor-in-Chief Forrest Shull discusses privacy implications for mobile and cloud computing with the John Howie, chief operating officer of the Cloud Security Alliance. He also looks at the upcoming Software Experts Summit scheduled for 30 May 2014 in Bangalore, India, and discusses the 200th episode of Software Engineering Radio. The Web extra at http://youtu.be/12w2q6BirV8 is an audio interview in which IEEE Software editor-in-chief Forrest Shull discusses the privacy implications of mobile and cloud computing with John Howie, chief operating officer of the Cloud Security Alliance.

Crowd Sourcing the Creation of Personae Non Gratae for Requirements-Phase Threat Modeling

Security threats should be identified in the early phases of a project so that design solutions can be explored and mitigating requirements specified. In this paper, we present a crowd-sourcing approach for creating Personae non Gratae (PnGs), which model attack goals and techniques of unwanted, potentially malicious users. We present a proof of concept study that takes a diverse collection of potentially redundant PnGs and merges them into a single set. Our approach combines machine learning techniques and visualization. It is illustrated and evaluated using a collection of PnGs collected from undergraduate students for a drone-based rescue scenario. Lessons learned from the proof of concept study are discussed and lay the foundations for future work.