Article

Technical Debt: Where Are the Shareholders' Interests?

Authors:
To read the full-text of this research, you can request a copy directly from the author.

Abstract

Technical debt is more than a metaphor: applying finance and accounting practices typical of other business obligations to technical debt can, in addition to meeting ethical and legal governance requirements, generate real, sustained financial benefits.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the author.

... No existe un proceso de software ideal y muchas organizaciones han desarrollado su propio enfoque para el desarrollo de software. La deuda técnica estudia formas de mantener el equilibrio entre el despliegue rápido y el valor a largo plazo [Kruchten01] y [Conroy01]. Un proceso subóptimo no se considera DP si no tiene un interés claro a pagar, como se ha postulado para la metáfora TD. ...
... La deuda técnica estudia formas de mantener el equilibrio entre el despliegue rápido y el valor a largo plazo[Kruchten01] y[Conroy01].Ph.D. César Jesús Pardo Calvache -Universidad del Cauca -cpardo@unicauca.edu.co -(+57) 3508479834 Doctorado en Ciencias de la Computación 2021 -Universidad del Cauca DEUDA DE PROCESOS (PD) Patrones y tipos de deuda de procesos Ph.D. César Jesús Pardo Calvache -Universidad del Cauca -cpardo@unicauca.edu.co ...
... Consequently, considering the technical debt strictly as software engineering processes put the enterprise at risk of not properly managing the interest of stakeholders. Conroy proposed to deal with technical debt as a financial obligation and record it in financial book [5]. There are several reasons to deal with technical debt as financial obligations: technical debt might have additional financial benefits for the firm such as reducing on revenue tax, capitalizing interest rate movement and gaining the return on currency arbitrage. ...
... Introducing technical debt as analogs of financial debt but not treating it as a financial commitment does not have any value added to projects. Additionally, not reporting technical debt is similar not disclosing financial debt and it may result in ethical and legal issues into enterprise [5]. Ampatzoglou et al. conducted a systematic literature review for investigating the financial aspect of technical debt. ...
Conference Paper
Full-text available
Technical debt is a metaphor in software engineering interpreted as a trade-off between short-term benefits of postponing development activities and long-term consequences of postponing those activities. Most of the research in technical debt literature focus on identifying technical debt, justifying what to include and what to exclude in the technical debt scope and how to deal with them: either to defer the development activity or to avoid debt. However, there are only a few studies which considered technical debt as a financial obligation. In this paper, we propose to record technical debt item in the balance sheet as a kind of liability. We also review the effect of having technical debt liabilities in the balance sheet.
... Technical debt studies ways to maintain the balance between rapid deployment and long-term value [5], [13].Fig. 1 sketches the notion of technical debt. Works proposed under the technical debt banner provide practitioners with methods and metrics for its evaluation and tracking [14], [15].Table I 1 contains an initial mapping between social debt and concepts/characteristics related to technical debt from [5], [6], [13]–[15]. ...
... Technical debt studies ways to maintain the balance between rapid deployment and long-term value [5], [13].Fig. 1 sketches the notion of technical debt. Works proposed under the technical debt banner provide practitioners with methods and metrics for its evaluation and tracking [14], [15].Table I 1 contains an initial mapping between social debt and concepts/characteristics related to technical debt from [5], [6], [13]–[15]. Column 1 explores technical debt characteristics; Column 2 summarises technical debt challenges; Column 3 matches technical debt with related concepts we can observe for social debt while Column 4 summarises our observations and challenges on social debt. ...
Conference Paper
Full-text available
“Social debt” in software engineering informally refers to unforeseen project cost connected to a “suboptimal” development community. The causes of suboptimal development communities can be many, ranging from global distance to organisational barriers to wrong or uninformed socio-technical decisions (i.e., decisions that influence both social and technical aspects of software development). Much like technical debt, social debt impacts heavily on software development success. We argue that, to ensure quality software engineering, practitioners should be provided with mechanisms to detect and manage the social debt connected to their development communities. This paper defines and elaborates on social debt, pointing out relevant research paths. We illustrate social debt by comparison with technical debt and discuss common real-life scenarios that exhibit “sub-optimal” development communities.
... Another approach is adopted in the work of Theodoropoulos et al. (2011), where a broad definitional framework of the Technical Debt from the stakeholder perspective is proposed, describing how technology gaps affect the quality within the technical environment. Establishing such a framework, would enable the technology stakeholders to build a conceptual model, better aligning their concerns (Conroy, 2012). On the contrary, the work of Wiklund et al. (2012) indicates that the test-driven development methods has become increasingly popular and elaborates on the fact that the development of test automation tools encounter problems due to unpredictable issues. ...
Chapter
Full-text available
Predicting and quantifying promptly the Technical Debt has turned into an issue of significant importance over recent years. In the cloud marketplace, where cloud services can be leased, the difficulty to identify the Technical Debt effectively can have a significant impact. In this chapter, the probability of introducing the Technical Debt due to budget and cloud service selection decisions is investigated. A cost estimation approach for implementing Software as a Service (SaaS) in the cloud is examined, indicating three scenarios for predicting the incurrence of Technical Debt in the future. The Constructive Cost Model (COCOMO) is used in order to estimate the cost of the implementation and define a range of secureness by adopting a tolerance value for prediction. Furthermore, a Technical Debt quantification approach is researched for leasing a cloud Software as a Service (SaaS) in order to provide insights about the most appropriate cloud service to be selected.
... Another approach is adopted in the work of Theodoropoulos et al. (2011), where a broad definitional framework of the Technical Debt from the stakeholder perspective is proposed, describing how technology gaps affect the quality within the technical environment. Establishing such a framework, would enable the technology stakeholders to build a conceptual model, better aligning their concerns (Conroy, 2012). On the contrary, the work of Wiklund et al. (2012) indicates that the test-driven development methods has become increasingly popular and elaborates on the fact that the development of test automation tools encounter problems due to unpredictable issues. ...
Chapter
Full-text available
Predicting and quantifying promptly the Technical Debt has turned into an issue of significant importance over recent years. In the cloud marketplace, where cloud services can be leased, the difficulty to identify the Technical Debt effectively can have a significant impact. In this chapter, the probability of introducing the Technical Debt due to budget and cloud service selection decisions is investigated. A cost estimation approach for implementing Software as a Service (SaaS) in the cloud is examined, indicating three scenarios for predicting the incurrence of Technical Debt in the future. The Constructive Cost Model (COCOMO) is used in order to estimate the cost of the implementation and define a range of secureness by adopting a tolerance value for prediction. Furthermore, a Technical Debt quantification approach is researched for leasing a cloud Software as a Service (SaaS) in order to provide insights about the most appropriate cloud service to be selected.
... Another approach is adopted in the work of Theodoropoulos et al. (2011), where a broad definitional framework of the Technical Debt from the stakeholder perspective is proposed, describing how technology gaps affect the quality within the technical environment. Establishing such a framework, would enable the technology stakeholders to build a conceptual model, better aligning their concerns (Conroy, 2012). On the contrary, the work of Wiklund et al. (2012) indicates that the test-driven development methods has become increasingly popular and elaborates on the fact that the development of test automation tools encounter problems due to unpredictable issues. ...
... This is because many of the causes of failures were interconnected to the cooperation and task backlog. Considering the values of the managers related to the defect fixing, we should understand that technical debt is not always a negative thing for the software product company [74]. ...
Article
Context Software project failures are common. Even though the reasons for failures have been widely studied, the analysis of their causal relationships is lacking. This creates an illusion that the causes of project failures are unrelated. Objective The aim of this study is to conduct in-depth analysis of software project failures in four software product companies in order to understand the causes of failures and their relationships. For each failure, we want to understand which causes, so called bridge causes, interconnect different process areas, and which causes were perceived as the most promising targets for process improvement. Method The causes of failures were detected by conducting root cause analysis. For each cause, we classified its type, process area, and interconnectedness to other causes. We quantitatively analyzed which type, process area, and interconnectedness categories (bridge, local) were common among the causes selected as the most feasible targets for process improvement activities. Finally, we qualitatively analyzed the bridge causes in order to find common denominators for the causal relationships interconnecting the process areas. Results For each failure, our method identified causal relationships diagrams including 130 to 185 causes each. All four cases were unique, albeit some similarities occurred. On average, 50% of the causes were bridge causes. Lack of cooperation, weak task backlog, and lack of software testing resources were common bridge causes. Bridge causes, and causes related to tasks, people, and methods were common among the causes perceived as the most feasible targets for process improvement. The causes related to the project environment were frequent, but seldom perceived as feasible targets for process improvement. Conclusion Prevention of a software project failure requires a case-specific analysis and controlling causes outside the process area where the failure surfaces. This calls for collaboration between the individuals and managers responsible for different process areas.
Article
Investment decisions related to information technology simultaneously constrain and facilitate prospective options. Hence, past and present decisions in relation to information technology investments impact future decisions and the maneuverability of organizational IT. The purpose of this paper is to develop and explore a new theory for better understanding how technology heritage impacts future decisions. The study expands a previous metaphor from software engineering and management (technical debt) into a broader theory of technology debt, and explores the proposed theory through the case of four investment decisions at a large, public university. As the findings show, there are clear indications of the theory being useful, and this is elaborated on in relation to future studies.
Article
Context The 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. Objective This 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. Method A systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated. Results We 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. Conclusion The results of this mapping study can help to identify points that still require further investigation in technical debt research.
Article
Full-text available
Context: Technical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. Objective: This work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. Method: A systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. Results: Ninety-four studies were finally selected. TD was classified into ten types, eight TDM activities were identified, and twenty-nine tools for TDM were collected. Conclusions: The term “debt” has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
Article
Full-text available
Context: Technical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. Objective: This work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. Method: A systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. Results: Ninety-four studies were finally selected. TD was classified into ten types, eight TDM activities were identified, and twenty-nine tools for TDM were collected. Conclusions: The term “debt” has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
ResearchGate has not been able to resolve any references for this publication.