Workshop MTD 2011 – Author Index |
Contents -
Abstracts -
Authors
|
Bohnet, Johannes |
![]() 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. ![]() |
|
Döllner, Jürgen |
![]() 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. ![]() |
|
Gat, Israel |
![]() 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. ![]() |
|
Gomes, Rebeka |
![]() 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. ![]() |
|
Guo, Yuepu |
![]() 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. ![]() |
|
Heintz, John D. |
![]() 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. ![]() |
|
Hofberg, Mark |
![]() 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. ![]() |
|
Kern, Daniel |
![]() 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. ![]() |
|
Klinger, Tim |
![]() 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. ![]() |
|
Kuipers, Tobias |
![]() 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. ![]() |
|
Marques, Rafael |
![]() 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. ![]() |
|
Nugroho, Ariadi |
![]() 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. ![]() |
|
Seaman, Carolyn B. |
![]() 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. ![]() ![]() 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. ![]() ![]() 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. ![]() |
|
Shaw, Michele |
![]() 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. ![]() |
|
Shull, Forrest |
![]() 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. ![]() ![]() 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. ![]() |
|
Tarr, Peri |
![]() 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. ![]() |
|
Theodoropoulos, Ted |
![]() 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. ![]() |
|
Visser, Joost |
![]() 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. ![]() |
|
Wagstrom, Patrick |
![]() 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. ![]() |
|
Williams, Clay |
![]() 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. ![]() |
|
Zazworka, Nico |
![]() 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. ![]() ![]() 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. ![]() |
25 authors
proc time: 0.05