ICSE 2012 Workshops
2012 34th International Conference on Software Engineering (ICSE)
Powered by
Conference Publishing Consulting

2012 Third International Workshop on Managing Technical Debt (MTD), June 5, 2012, Zurich, Switzerland

MTD 2012 – Proceedings

Contents - Abstracts - Authors

Third International Workshop on Managing Technical Debt (MTD)

Preface

Title Page


Foreword
The technical debt metaphor has gained significant traction in the software development community as a way to understand and communicate issues of intrinsic quality, value, and cost in the past few years. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a ""debt"" on which ""interest"" has to be paid and which should be repaid at some point for the long-term health of the project. Little is known about technical debt, beyond feelings and opinions. The software engineering research community has an opportunity to study this phenomenon and improve the way it is handled. We can offer software engineers a foundation for managing such trade-offs based on models of their economic impacts. The goal of this third workshop is to discuss managing technical debt as a part of the research agenda for the software engineering field, in particular focusing on eliciting and visualizing debt, and creating pay-back strategies.

Searching for Build Debt: Experiences Managing Technical Debt at Google
J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc, and Sanjay Bhansali
(Google, USA)
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.

Visualising Architectural Dependencies
John Brondum and Liming Zhu
(NICTA, Australia; University of New South Wales, Australia)
Visibility of technical debt is critical. A lack thereof can lead to significant problems without adequate visibility as part of the system level decision-making processes [2]. Current approaches for analysing and monitoring architecture related debt are based on dependency analysis to detect code level violations of the software architecture [2,3,6]. However, heterogeneous environments with several systems constructed using COTS, and/or several programming languages may not offer sufficient code visibility. Other limiting factors include legal contracts, Intellectual Property Rights, and just very large systems. Secondly, the complexity of a software dependency is often greater than simple structural dependencies, including; multi-dimensional properties (as argued by [10]); behavioural dependencies [5,9]; and ‘implicit’ dependencies (i.e., dependency inter-relatedness [11]). This paper proposes a simple modelling approach for visualising dependency relationships as an extension of the current approaches, while supporting complex dependencies. The model can be built using existing dependency analysis and general architectural knowledge; thus is better suited for heterogeneous environments. We demonstrate the proposed modelling using an exemplar, and two field case studies.

Investigating the Impact of Code Smells Debt on Quality Code Evaluation
Francesca Arcelli Fontana, Vincenzo Ferme, and Stefano Spinelli
(University of Milano-Bicocca, Italy; Blue Reply, Italy)
Different forms of technical debt exist that have to be carefully managed. In this paper we focus our attention on design debt, represented by code smells. We consider three smells that we detect in open source systems of different domains. Our principal aim is to give advice on which design debt has to be paid first, according to the three smells we have analyzed. Moreover, we discuss if the detection of these smells could be tailored to the specific application domain of a system.

Organizing the Technical Debt Landscape
Clemente Izurieta, Antonio Vetrò, Nico Zazworka, Yuanfang Cai, Carolyn B. Seaman, and Forrest Shull
(Montana State University, USA; Politecnico di Torino, Italy; Fraunhofer CESE, USA; Drexel University, USA; University of Maryland in Baltimore County, USA)
To date, several methods and tools for detecting source code and design anomalies have been developed. While each method focuses on identifying certain classes of source code anomalies that potentially relate to technical debt (TD), the overlaps and gaps among these classes and TD have not been rigorously demonstrated. We propose to construct a seminal technical debt landscape as a way to visualize and organize research on the subject.

Technical Debt Aggregation in Ecosystems
John D. McGregor, J. Yates Monteith, and Jie Zhang
(Clemson University, USA)
The members of the ecosystem encompassing our organization are affected by our decisions just as we are affected by their decisions. If an organization takes on technical debt with respect to a specific asset, that decision will affect users of the asset either directly or indirectly. In this position paper we distinguish between incurring technical debt directly and experiencing the effects of technical debt indirectly. We illustrate why two separate concepts are needed for a complete theory and provide examples from ecosystem models we have created for several organizations. The result is a model that produces good explanations for posited scenarios.

The SQALE Method for Evaluating Technical Debt
Jean-Louis Letouzey
(inspearit, France)
This paper presents the SQALE (Software Quality Assessment Based on Lifecycle Expectations) method. We describe its Quality Model and Analysis Model which are used to estimate the Quality and the Technical Debt of an application source code. We provide recommendations and guidelines for using the SQALE indicators in order to analyse the structure and the impact of the Technical Debt.

What Is the Value of Your Software?
Jelle de Groot, Ariadi Nugroho, Thomas Bäck, and Joost Visser
(Software Improvement Group, Netherlands; Leiden University, Netherlands; Radboud University Nijmegen, Netherlands)
Assessment of the economic value of software systems is useful in contexts such as capitalization on the balance sheet and due diligence prior to acquisition. Current accounting practice in determining software value is based on the cost spent in software development. This approach fails to account for the efficiency with which software has been produced or the quality of the product. This paper proposes three alternative models for determining the production value of software, based on the notions of technical debt and interest. We applied the models to 367 proprietary systems developed by a range of different organisations using a range of different programming languages. We present the valuation results and discuss the weaknesses and strengths of the models.

Using Technical Debt Data in Decision Making: Potential Decision Approaches
Carolyn B. Seaman, Yuepu Guo, Clemente Izurieta, Yuanfang Cai, Nico Zazworka, Forrest Shull, and Antonio Vetrò
(University of Maryland in Baltimore County, USA; Montana State University, USA; Drexel University, USA; Fraunhofer CESE, USA; Politecnico di Torino, Italy)
The management of technical debt ultimately requires decision making – about incurring, paying off, or deferring technical debt instances. This position paper discusses several existing approaches to complex decision making, and suggests that exploring their applicability to technical debt decision making would be a worthwhile subject for further research.

Estimating the Size, Cost, and Types of Technical Debt
Bill Curtis, Jay Sappidi, and Alexandra Szynkarski
(CAST, USA; CAST, France)
This study summarizes results of a study of Technical Debt across 745 business applications comprising 365 million lines of code collected from 160 companies in 10 industry segments. These applications were submitted to a static analysis that evaluates quality within and across application layers that may be coded in different languages. The analysis consists of evaluating the application against a repository of over 1200 rules of good architectural and coding practice. A formula for estimating Technical Debt with adjustable parameters is presented. Results are presented for Technical Debt across the entire sample as well as for different programming languages and quality factors.

Defining the Decision Factors for Managing Defects: A Technical Debt Perspective
Will Snipes, Brian Robinson, Yuepu Guo, and Carolyn B. Seaman
(ABB, USA; University of Maryland in Baltimore County, USA)
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.

On the Role of Requirements in Understanding and Managing Technical Debt
Neil A. Ernst
(University of British Columbia, Canada)
Technical debt is the trading of long-term software quality in favor of short-term expediency. While the concept has traditionally been applied to tradeoffs at the code and architecture phases, it also manifests itself in the system requirements analysis phase. Little attention has been paid to requirements over time in software: requirements are often badly out of synch with the implementation, or not used at all. However, requirements are the ultimate validation of project success, since they are the manifestation of the stakeholder’s desires for the system. In this position paper, we define technical debt in requirements as the distance between the implementation and the actual state of the world. We highlight how a requirements modeling tool, RE-KOMBINE, makes requirements, domain constraints and implementation first-class concerns. RE-KOMBINE represents technical debt using the notion of optimal solutions to a requirements problem. We show how this interpretation of technical debt may be useful in deciding how much requirements analysis is sufficient.

proc time: 0.03