Powered by
Second International Workshop on Managing Technical Debt (MTD 2011),
May 23, 2011,
Waikiki, Honolulu, HI, USA
Second International Workshop on Managing Technical Debt (MTD 2011)
Preface
Foreword
Welcome to the Second International Workshop on Managing Technical Debt, MTD 2011, co-located with the 33rd International Conference on Software Engineering at Waikiki, Honolulu, Hawaii!
The first workshop on technical debt was held at the Software Engineering Institute in Pittsburgh on June 2 to 4, 2010 with the goal of understanding open research questions related to managing technical debt in software. The goal of this second workshop is to come up with a more in-depth understanding of technical debt, its definition(s), characteristics, its different forms. For this second workshop we accepted 3 research and 7 position papers. The papers were selected after a peer review by at least three members of the program committee. The accepted submissions cover a range of topics such as: monitoring and visualizing code quality, relationship of technical debt and maintainability, an economic model for technical debt and interest, software architecture related technical debt, and definitional foundations of technical debt.
Full Papers
An Empirical Model of Technical Debt and Interest
Ariadi Nugroho, Joost Visser, and Tobias Kuipers
(Software Improvement Group, Netherlands)
Cunningham introduced the metaphor of technical debt as guidance for software developers that must trade engineering quality against short-term goals.
We revisit the technical debt metaphor, and translate it into terms that can help IT executives better understand their IT investments. An approach is proposed to quantify debts (cost to fix technical quality issues) and interest (extra cost spent on maintenance due to technical quality issues). Our approach is based on an empirical assessment method of software quality developed at the Software Improvement Group (SIG). The core part of the technical debt calculation is constructed on the basis of empirical data of 44 systems that are currently being monitored by SIG.
In a case study, we apply the approach to a real system, and discuss how the results provide useful insights on important questions related to IT investment such as the return on investment (ROI) in software quality improvement.
@InProceedings{MTD11p1,
author = {Ariadi Nugroho and Joost Visser and Tobias Kuipers},
title = {An Empirical Model of Technical Debt and Interest},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {1--8},
doi = {},
year = {2011},
}
Monitoring Code Quality and Development Activity by Software Maps
Johannes Bohnet and Jürgen Döllner
(Hasso-Plattner-Institute at the University of Potsdam, Germany)
Software development projects are difficult to manage, in general, due to the friction between completing system features and, at the same time, obtaining a high degree of code quality to ensure maintainability of the system in the future. A major challenge of this optimization problem is that code quality is less visible to stakeholders in the development process, particularly, to the management. In this paper, we describe an approach for automated software analysis and monitoring of both quality-related code metrics and development activities by means of software maps. A software map represents an adaptive, hierarchical representation of software implementation artifacts such as source code files being organized in a modular hierarchy. The maps can express and combine information about software development, software quality, and system dynamics; they can systematically be specified, automatically generated, and organized by templates. The maps aim at supporting decision-making processes. For example, they facilitate to decide where in the code an increase of quality would be beneficial both for speeding up current development activities and for reducing risks of future maintenance problems. Due to their high degree of expressiveness and their instantaneous generation, the maps additionally serve as up-to-date information tools, bridging an essential information gap between management and development, improve awareness, and serve as early risk detection instrument. The software map concept and its tool implementation are evaluated by means of two case studies on large industrially developed software systems.
@InProceedings{MTD11p9,
author = {Johannes Bohnet and Jürgen Döllner},
title = {Monitoring Code Quality and Development Activity by Software Maps},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {9--16},
doi = {},
year = {2011},
}
Investigating the Impact of Design Debt on Software Quality
Nico Zazworka, Michele Shaw, Forrest Shull, and Carolyn B. Seaman
(Fraunhofer CESE, USA; UMBC, USA)
Technical debt is a metaphor describing situations where developers accept sacrifices in one dimension of development (e.g. software quality) in order to optimize another dimension (e.g. implementing necessary features before a deadline). Approaches, such as code smell detection, have been developed to identify particular kinds of debt, e.g. design debt. What has not yet been understood is the impact design debt has on the quality of a software product. Answering this question is important for understanding how growing debt affects a software product and how it slows down development, e.g. though introducing rework such as fixing bugs. In this case study we investigate how design debt, in the form of god classes, affects the maintainability and correctness of software products by studying two sample applications of a small-size software development company. The results show that god classes are changed more often and contain more defects than non-god classes. This result complements findings of earlier research and suggests that technical debt has a negative impact on software quality, and should therefore be identified and managed closely in the development process.
@InProceedings{MTD11p17,
author = {Nico Zazworka and Michele Shaw and Forrest Shull and Carolyn B. Seaman},
title = {Investigating the Impact of Design Debt on Software Quality},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {17--23},
doi = {},
year = {2011},
}
Short Papers
From Assessment to Reduction: How Cutter Consortium Helps Rein in Millions of Dollars in Technical Debt
Israel Gat and John D. Heintz
(Cutter Consortium, USA; Gist Labs, USA)
Technical debt assessments often follow a similar pattern across engagements. In contrast, technical debt reduction projects can vary significantly from one company to another. In addition to exposing unexpected technical challenges, technical debt reduction projects bring business issues, organizational consideration, and methodical questions to the fore. This paper outlines how all these aspects are being dealt with in a Cutter Consortium engagement with a client that struggles to wrestle technical debt to the ground.
@InProceedings{MTD11p24,
author = {Israel Gat and John D. Heintz},
title = {From Assessment to Reduction: How Cutter Consortium Helps Rein in Millions of Dollars in Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {24--26},
doi = {},
year = {2011},
}
An Extraction Method to Collect Data on Defects and Effort Evolution in a Constantly Modified System
Rebeka Gomes and
Rafael Marques
(UFPE, Brazil)
This paper describes a data extraction method that was carried out on a set of historical development documentation, related to a commercial software system for mobile platform. This method is part of a major project, which aims to identify evidences of technical debt via the analysis of the defect evolution and effort estimation deviation, verifying if there are relations between these concepts and project decisions during the cycles of development. We intend that a future analysis of such data supports the identification of patterns regarding specific decisions and variations of the defect number/frequency and effort deviation. Thus, such patterns could assist project managers during future project decisions, mainly regarding the maintenance and evolution stages.
@InProceedings{MTD11p27,
author = {Rebeka Gomes and Rafael Marques},
title = {An Extraction Method to Collect Data on Defects and Effort Evolution in a Constantly Modified System},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {27--30},
doi = {},
year = {2011},
}
A Portfolio Approach to Technical Debt Management
Yuepu Guo and Carolyn B. Seaman
(University of Maryland Baltimore County, USA)
Technical debt describes the effect of immature software artifacts on software maintenance – the potential of extra effort required in future as if paying interest for the incurred debt. The uncertainty of interest payment further complicates the problem of what debt should be incurred or repaid and when. To help software managers make informed decisions, a portfolio approach is proposed in this paper. The approach leverages the portfolio management theory in the finance domain to determine the optimal collection of technical debt items that should be incurred or held. We expect this approach could provide a new perspective for technical debt management.
@InProceedings{MTD11p31,
author = {Yuepu Guo and Carolyn B. Seaman},
title = {A Portfolio Approach to Technical Debt Management},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {31--34},
doi = {},
year = {2011},
}
An Enterprise Perspective on Technical Debt
Tim Klinger, Peri Tarr, Patrick Wagstrom, and Clay Williams
(IBM Watson Research, USA)
Technical debt is a term that has been used to describe the
increased cost of changing or maintaining a system due to
expedient shortcuts taken during its development. Much of the
research on technical debt has focused on decisions made by
project architects and individual developers who choose to trade
off short-term gain for a longer-term cost. However, in the context
of enterprise software development, such a model may be too
narrow. We explore the premise that technical debt within the
enterprise should be viewed as a tool similar to financial leverage,
allowing the organization to incur debt to pursue options that it
couldn’t otherwise afford. We test this premise by interviewing a
set of experienced architects to understand how decisions to
acquire technical debt are made within an enterprise, and to what
extent the acquisition of technical debt provides leverage. We find
that in many cases, the decision to acquire technical debt is not
made by technical architects, but rather by non-technical
stakeholders who cause the project to acquire new technical debt
or discover existing technical debt that wasn’t previously visible.
We conclude with some preliminary observations and
recommendations for organizations to better manage technical
debt in the presence of some enterprise-scale circumstances.
@InProceedings{MTD11p35,
author = {Tim Klinger and Peri Tarr and Patrick Wagstrom and Clay Williams},
title = {An Enterprise Perspective on Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {35--38},
doi = {},
year = {2011},
}
Prioritizing Design Debt Investment Opportunities
Nico Zazworka, Carolyn B. Seaman, and Forrest Shull
(Fraunhofer CESE, USA; UMBC, USA)
Technical debt is the technical work developers owe a system, typically caused by speeding up development, e.g. before a software release. Approaches, such as code smell detection, have been developed to identify particular kinds of debt, e.g. design debt. Up until now, code smell detection has been used to help point to components that need to be freed from debt by refactoring. To date, a number of methods have been described for finding code smells in a system. However, typical debt properties, such as the value of the debt and interest rate to be paid, have not been well established. This position paper proposes an approach to using cost/benefit analysis to prioritize technical debt reduction work by ranking the value and interest of design debt caused by god classes. The method is based on metric analysis and software repository mining and is demonstrated on a commercial software application at a mid size development company. The results are promising: the method helps to identify which refactoring activities should be performed first because they are likely to be cheap to make yet have significant effect, and which refactorings should be postponed due to high cost and low payoff.
@InProceedings{MTD11p39,
author = {Nico Zazworka and Carolyn B. Seaman and Forrest Shull},
title = {Prioritizing Design Debt Investment Opportunities},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {39--42},
doi = {},
year = {2011},
}
Technical Debt from the Stakeholder Perspective
Ted Theodoropoulos, Mark Hofberg, and Daniel Kern
(Acrowire, USA)
The concept of technical debt provides an excellent tool for describing technology gaps in terms any stakeholder can understand. The technical debt metaphor was pioneered by the software development community and describes technical challenges in that context wonderfully. However, establishing a definitional framework which describes issues affecting quality more broadly will better align to stakeholder perspectives. Building on the existing concept in this way will enable technology stakeholders by providing a centralized technical debt model. The metaphor can then be used to consistently describe quality challenges anywhere within the technical environment. This paper lays the foundation for this conceptual model by proposing a definitional framework that describes how technology gaps affect all aspects of quality.
@InProceedings{MTD11p43,
author = {Ted Theodoropoulos and Mark Hofberg and Daniel Kern},
title = {Technical Debt from the Stakeholder Perspective},
booktitle = {Proc.\ MTD},
publisher = {ACM},
pages = {43--46},
doi = {},
year = {2011},
}
proc time: 0.03