ICSE 2013 - May 18-26, 2013, San Francisco, CA, USA
Powered by
Conference Publishing Consulting

2013 4th International Workshop on Managing Technical Debt (MTD), May 20, 2013, San Francisco, CA, USA

MTD 2013 – Proceedings

Contents - Abstracts - Authors

4th International Workshop on Managing Technical Debt (MTD)

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. 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. While there is increased attention to understanding what technical debt is and is not, still little is known about how to systematically understand and manage technical debt, if at all. 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 fourth workshop is to discuss managing technical debt as a part of the research agenda for the software engineering field, in particular focusing on eliciting case studies from industry, visualizing debt and creating payback strategies.
Investigating Technical Debt Folklore: Shedding Some Light on Technical Debt Opinion
Rodrigo O. Spínola, Nico Zazworka, Antonio Vetrò, Carolyn Seaman, and Forrest Shull
(Universidade Salvador, Brazil; Elsevier Information Systems, Germany; Politecnico di Torino, Italy; University of Maryland in Baltimore County, USA; Fraunhofer CESE, USA)
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.
Article Search
Managing Technical Debt: An Industrial Case Study
Zadia Codabux and Byron Williams
(Mississippi State University, USA)
Technical debt is the consequence of trade-offs made during software development to ensure speedy releases. The research community lacks rigorously evaluated guidelines to help practitioners characterize, manage and prioritize debt. This paper describes a study conducted with an industrial partner during their implementation of Agile development practices for a large software development division within the company. The report contains our initial findings based on ethnographic observations and semi-structured interviews. The goal is to identify the best practices regarding managing technical debt so that the researchers and the practitioners can further evaluate these practices to extend their knowledge of the technical debt metaphor. We determined that the developers considered their own taxonomy of technical debt based on the type of work they were assigned and their personal understanding of the term. Despite managements high-level categories, the developers mostly considered design debt, testing debt and defect debt. In addition to developers having their own taxonomy, assigning dedicated teams for technical debt reduction and allowing other teams about 20% of time per sprint for debt reduction are good initiatives towards lowering technical debt. While technical debt has become a well-regarded concept in the Agile community, further empirical evaluation is needed to assess how to properly apply the concept for various development organizations.
Article Search
Practical Considerations, Challenges, and Requirements of Tool-Support for Managing Technical Debt
Davide Falessi, Michele A. Shaw, Forrest Shull, Kathleen Mullen, and Mark Stein
(Fraunhofer CESE, USA; Keymind, USA)
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.
Article Search
DebtFlag: Technical Debt Management with a Development Environment Integrated Tool
Johannes Holvitie and Ville Leppänen
(Turku Centre for Computer Science, Finland; University of Turku, Finland)
In this paper, we introduce the DebtFlag tool for capturing, tracking and resolving technical debt in software projects. DebtFlag integrates into the development environment and provides developers with lightweight documentation tools to capture technical debt and link them to corresponding parts in the implementation. During continued development these links are used to create propagation paths for the documented debt. This allows for an up-to-date and accurate presentation of technical debt to be upheld, which enables developer conducted implementation-level micromanagement as well as higher level technical debt management.
Article Search
Understanding the Impact of Technical Debt on the Capacity and Velocity of Teams and Organizations: Viewing Team and Organization Capacity as a Portfolio of Real Options
Ken Power
(Cisco Systems, Ireland)
Understanding the impact of technical debt is critical to understanding a team’s velocity. For organizations with multiple teams and products, the impact of technical debt combines non-linearly to impact the organization’s velocity. We can think of the capacity of a team as a portfolio. Not all of that capacity can be invested in new features or defect fixing, without incurring negative consequences. A portion of the team’s capacity needs to be invested in the ongoing management and reduction of technical debt. This paper describes a simple technique for visualizing, quantifying and tracking a team’s technical debt as a portion of their overall capacity investment. The knowledge and insights gained through this technique help with better capacity planning, improved forecasting, and helps to justify the business case for investing in managing and reducing technical debt.
Article Search
Exploring Software Supply Chains From a Technical Debt Perspective
J. Yates Monteith and John D. McGregor
(Clemson University, USA)
Software development has evolved from software development organizations building custom solutions for every need and creating a backlog of applications needed by users to specialized organizations producing components that are supplied to other software development organizations to speed the development of their software products. Our objective is to illustrate how a manager might use supply chain information to evaluate software being considered for inclusion in a product. We investigated the Eclipse platform code to illustrate analysis methods that produce information of use to decision makers. The technical debt of the software pieces was measured using the Technical Debt plug-in to Sonar as one input into the evaluation of supply chain quality. The dependency graphs of “uses” relationships among files were analyzed using graph metrics such as betweenness centrality. There was a statistically significant moderate correlation between the technical debt for a file and the betweenness centrality for that file. This relationship is used as the basis for a heuristic approach to forming advice to a development manager regarding which assets to acquire.
Article Search
Mapping Architectural Decay Instances to Dependency Models
Ran Mo, Joshua Garcia, Yuanfang Cai, and Nenad Medvidovic
(Drexel University, USA; University of Southern California, USA)
Abstract—The architectures of software systems tend to drift or erode as they are maintained and evolved. These systems often develop architectural decay instances, which are instances of design decisions that negatively impact a system’s lifecycle properties and are the analog to code-level decay instances that are potential targets for refactoring. While code-level decay instances are based on source-level constructs, architectural decay instances are based on higher levels of abstractions, such as components and connectors, and related concepts, such as concerns. Unlike code-level decay instances, architectural decay usually has more significant consequences. Not being able to detect or address architectural decay in time incurs architecture debt that may result in a higher penalty in terms of quality and maintainability (interest) over time. To facilitate architecture debt detection, in this paper, we demonstrate the possibility of transforming architectural models and concerns into an extended augmented constraint network (EACN), which can uniformly model the constraints among design decisions and environmental conditions. From an ACN, a pairwise-dependency relation (PWDR) can be derived, which, in turn, can be used to automatically and uniformly detect architectural decay instances.
Article Search
Generating Precise Dependencies for Large Software
Pei Wang, Jinqiu Yang, Lin Tan, Robert Kroeger, and J. David Morgenthaler
(University of Waterloo, Canada; Google, Canada; Google, USA)
Intra- and inter-module dependencies can be a significant source of technical debt in the long-term software development, especially for large software with millions of lines of code. This paper designs and implements a precise and scalable tool that extracts code dependencies and their utilization for large C/C++ software projects. The tool extracts both symbol-level and module-level dependencies of a software system and identifies potential underutilized and inconsistent dependencies. Such information points to potential refactoring opportunities and help developers perform large-scale refactoring tasks.
Article Search
Towards a Model for Optimizing Technical Debt in Software Products
Narayan Ramasubbu and Chris F. Kemerer
(University of Pittsburgh, USA)
There is a growing interest in applying the technical debt metaphor to investigate issues related to the tradeoff of the likely long-term costs associated with software design shortcuts for expected short-term business benefits in terms of increased earlier functionality. We propose an optimization model that contrasts the patterns of technical debt accumulation in a software product with the patterns of consumer adoption of the software product throughout its evolution. This facilitates a rigorous and balanced analysis of the pros and cons of accumulating technical debt at various lifecycle stages of a software product. We discuss the use of the optimization model to derive policies for managing technical debt and the potential for empirical tests of the model and other future interdisciplinary research.
Article Search
CloudMTD: Using Real Options to Manage Technical Debt in Cloud-Based Service Selection
Esra Alzaghoul and Rami Bahsoon
(University of Birmingham, UK)
In cloud marketplace, cloud-based system architectures can be composed of web services, which are leased or bought off the cloud. These architectures can add value to its composition by switching and substituting its constituent services. The value-added can relate to improved Quality of Service (QoS), new revenue streams by enabling new business models, reduced operational cost and so forth. The selection and substitution decisions may introduce a technical debt, however. We specifically look at the debt of substitution decisions in support for scaling up scenarios. This debt may need to be managed, cleared and transformed to value-added. We take an option-based approach to inform the selection of candidate web services with varying debt. For every selection, we quantify the extent to which it can clear the debt and provide future options.
Article Search
On the Limits of the Technical Debt Metaphor: Some Guidance on Going Beyond
Klaus Schmid
(University of Hildesheim, Germany)
Over recent years the topic of technical debt has gained significant attention in the software engineering community. The area of technical debt research is somewhat peculiar within software engineering as it is built on a metaphor. This has certainly benefited the field as it helps to achieve a lot of attention and eases communication about the topic, however, it seems it is to some extent also sidetracking research work, if the metaphor is used beyond its range of applicability. In this paper, we focus on the limits of the metaphor and the problems that arise when over-extending its applicability. We do also aim at providing some additional insights by proposing certain ways of handling these restrictions.
Article Search

proc time: 0.21