Context: The term technical debt (TD) describes the aggregation of sub-optimal solutions that ser... more Context: The term technical debt (TD) describes the aggregation of sub-optimal solutions that serve to impede the evolution and maintenance of a system. Some claim that the broken windows theory (BWT), a concept borrowed from criminology, also applies to software development projects. The theory states that the presence of indications of previous crime (such as a broken window) will increase the likelihood of further criminal activity; TD could be considered the broken windows of software systems. Objective: To empirically investigate the causal relationship between the TD density of a system and the propensity of developers to introduce new TD during the extension of that system. Method: The study used a mixed-methods research strategy consisting of a controlled experiment with an accompanying survey and follow-up interviews. The experiment had a total of 29 developers of varying experience levels completing system extension tasks in already existing systems with high or low TD density. Results: The analysis revealed significant effects of TD level on the subjects' tendency to re-implement (rather than reuse) functionality, choose non-descriptive variable names, and introduce other code smells identified by the software tool SonarQube, all with at least 95% credible intervals.
Background: In order to survive in today's fast-growing and ever fast-changing business environme... more Background: In order to survive in today's fast-growing and ever fast-changing business environment, software companies need to continuously deliver customer value, both from a short-and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process. Objective: The overarching goal of this Ph.D. thesis is twofold. The first goal is to empirically study and understand in what way and to what extent, TD influences today's software development work, specifically with the intention to provide more quantitative insight into the field. Second, to understand which different initiatives can reduce the negative effects of TD and also which factors are important to consider when implementing such initiatives. Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, analysis of documents, correlation analysis, and statistical tests. In seven of the eleven studies included in this Ph.D. thesis, a combination of multiple research methods are used to achieve high validity. Results: We present results showing that software suffering from TD will cause various negative effects on both the software and the developing process. These negative effects are illustrated from a technical, financial, and a developer's working situational perspective. These studies also identify several initiatives that can be undertaken in order to reduce the negative effects of TD. Conclusion: The results show that software developers report that they waste 23% of their working time due to experiencing TD and that TD required them to perform additional time-consuming work activities. This study also shows that, compared to all types of TD, architectural TD has the greatest negative impact on daily software development work and that TD has negative effects on several different software quality attributes. Further, the results show that TD reduces developer morale. Moreover, the findings show that intentionally introducing TD in startup companies can allow the startups to cut development time, enabling faster feedback and increased revenue, preserve resources, and decrease risk and thereby contribute to beneficial effects. This study also identifies several initiatives that can be undertaken in order to reduce the negative effects of TD, such as the introduction of a tracking process where the TD items are introduced in an official backlog. The finding also indicates that there is an unfulfilled potential regarding how managers can influence the manner in which software practitioners address TD.
Background: In order to survive in today's fast-growing and ever fast-changing business environme... more Background: In order to survive in today's fast-growing and ever fast-changing business environments, large-scale software companies need to deliver customer value continuously, both from a short-and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process. Objective: The overall goal of this Licentiate thesis is to empirically study and understand in what way and to what extent, TD in general and architectural TD specifically, influence today's software development work and, specifically, with the intention of providing more quantitative insights into the field. Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, correlation analysis, and statistical tests. In five of the seven included studies, we use a combination of multiple research methods to achieve high validity. Results: We present results showing that software suffering from TD will cause various different negative effects on both the software and on the developing process. These negative effects can be illustrated from a technical, a financial and from a developer's working situational perspective. Conclusion: This thesis contributes to the understanding and quantification of in what way and to what extent TD is harmful to software development organizations. The results show that software practitioners estimate that they waste 36% of their working time due to experiencing TD and that the TD is causing them to perform additional timeconsuming work activities. This study also shows that, compared to all types of TD, architectural TD has the greatest negative impact on the daily software development work.
Context: When developing software, it is vitally important to keep the level of technical debt do... more Context: When developing software, it is vitally important to keep the level of technical debt down since it is well established from several studies that technical debt can, e.g., lower the development productivity, decrease the developers' morale, and compromise the overall quality of the software. However, even if researchers and practitioners working in today's software development industry are quite familiar with the concept of technical debt and its related negative consequences, there has been no empirical research focusing specifically on how software managers actively communicate and manage the need to keep the level of technical debt as low as possible. Objective: This study aims to understand how software companies give incentives to manage Technical Debt. This is done by exploring how companies encourage and reward practitioners for actively keeping the level of technical debt down and whether the companies use any forcing or penalizing initiatives when managing technical debt. Method: In a first step, this paper reports the results of both an online survey provided quantitative data from 258 participants and interviews with 32 software practitioners. In a second step, this study set out to specifically provide a detailed assessment of additional and in-depth analysis of Technical Debt management strategies based on an encouraging mindset and attitude from both managers and technical roles to understand how, when and by whom such strategy is adopted in practice. Results: Our findings show that having a Technical Debt management strategy (specially based on encouragement) can significantly impact the amount of Technical Debt in the software. Conclusion: The result indicates that there is considerable unfulfilled potential to influence how software practitioners can further limit and reduce Technical Debt by adopting a strategy based explicitly on an encouraging mindset from managers where they also specifically dedicate time and resources for Technical Debt remediation activities.
Software companies need to deliver customer value continuously, both from a shortand long-term pe... more Software companies need to deliver customer value continuously, both from a shortand long-term perspective. However, software development can be impeded by technical debt (TD). Although significant theoretical work has been undertaken to describe the negative effects of TD, little empirical evidence exists on how much wasted time and additional activities TD causes. The study aims to explore the consequences of TD in terms of wastage of development time. This study investigates on which activities this wasted time is spent and whether different TD types impact the wasted time differently. This study reports the results of a longitudinal study surveying 43 developers and including16 interviews followed by validation by an additional study using a different and independent dataset and focused on replicating the findings addressing the findings. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their time due to TD and that developers are frequently forced to introduce new TD. The most common activity on which additional time is spent is performing additional testing. The study provides evidence that TD hinders developers by causing an excessive waste of working time, where the wasted time negatively affects productivity.
Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it i... more Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring of Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review of 557 unique papers published until 2020, following a consolidated methodology applied in software engineering. We included 44 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that Technical Debt prioritization research is preliminary and there is no consensus on what the important factors are and how to measure them. Consequently, we cannot consider current research
The Enterprise Architect profession: An empirical study
The field of Enterprise Architecture (EA) is rapidly evolving why there is a need for increased p... more The field of Enterprise Architecture (EA) is rapidly evolving why there is a need for increased professionalization of the discipline. Therefore, understanding the profession of the Enterprise Architects in enterprise transformation and development becomes important. However, there are very few empirically based studies which have reflected these professionals within their work domain of an every-day business. The purpose of this paper is to increase our understanding of how the Enterprise Architect’s practice their profession and in addition, to study how these professionals describe their occupation. Five different topics are of particular interest to portraying the occupation of the Enterprise Architect's profession; the role, competence, power, style of acting and main focus. The research is a descriptive study based on interviews with Enterprise Architects in ten large Swedish organizations. In conclusion, the architect is considered as a proud individualist with an entrepreneurial vein who endeavor consideration, reflection, and the guidance capability.
The present trend shows that Enterprise Architecture (EA) is an essential resource to improve the... more The present trend shows that Enterprise Architecture (EA) is an essential resource to improve the organizational efficiency, effectiveness, and agility, both in the business and the technology environment. The Enterprise Architect professionals who are working in this area are thus essential for operations in organizational transformation and development, therefore, vital to understand the ambition of this profession. There are several academic studies available concerning EA. However, there are few empirically based studies which in particularly reflect the Enterprise Architect profession. This study, examining the profession of the Enterprise Architect, sheds new light on what these professionals do within their organization on an everyday basis and how this view differs from how the profession is described in existing research. The purpose of this paper is to explore and compare how the Enterprise Architect profession is described both by academics and by empirically collected data. We perceive five topics that are essential to a comprehensive, rich picture of the profession; the role, competence, power, style of acting and main focus. The study is based on an initial literature survey and an empirically based study based on interviews with Enterprise Architects in ten large Swedish organizations. Our interviews show that the architect's work in several aspects is consistent with the literature but in other respects, an evident dissimilarity is revealed. One of the most obvious differences is the architect's mindset in terms of working in a reactive or a proactive way. Our interviews show that architects are working primarily in a reactive approach both in terms of how their roles are described but also in relation to how the EA function is set up. Although it is evidential that most of the architects' work is based on a reactive basis, the architects claim it would be inappropriate with a purely proactive approach. Nevertheless, the establishment of the EA as a function within the interviewed organizations seems to have been well implemented, where architectural principles are determined as mandatory, while an interesting finding is that major or radical IT investments appears to overrule the architectural principles and is part of top management discretion only.
Context Software engineering is a human activity. Despite this, human aspects are underrepresente... more Context Software engineering is a human activity. Despite this, human aspects are underrepresented in technical debt research, perhaps because they are challenging to evaluate. Objective This study's objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Method Forty participants (N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures (r = 5) experiment (n = 200), a survey, and semi-structured interviews. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioners' reactions to technical debt appear to fall in different levels of maturity. Results The statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states. Conclusions We argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.
Remediation of technical debt through regular refactoring initiatives is considered vital for the... more Remediation of technical debt through regular refactoring initiatives is considered vital for the software system's long and healthy life. However, since today's software companies face increasing pressure to deliver customer value continuously, the balance between spending developer time, effort, and resources on implementing new features or spending it on refactoring of technical debt becomes vital. The goal of this study is to explore how the prioritization of technical debt is carried out by practitioners within today's software industry. This study also investigates what factors influence the prioritization process and its related challenges. This paper reports the results of surveying 17 software practitioners, together with follow-up interviews with them. Our results show that there is no uniform way of prioritizing technical debt and that it is commonly done reactively without applying any explicit strategies. Often, technical debt issues are managed and prioritized in a shadow backlog, separate from the official sprint backlog. This study was also able to identify several different challenges related to prioritizing technical debt, such as the lack of quantitative information about the technical debt items and that the refactoring of technical debt issues competes with the implementation of customer requirements.
The Pricey Bill of Technical Debt: When and by Whom will it be Paid?
Software companies need to support continuous and fast delivery of customer value both in short a... more Software companies need to support continuous and fast delivery of customer value both in short and a long-term perspective. However, this can be hindered by evolution limitations and high maintenance efforts due to internal software quality issues by what is described as Technical Debt. Although significant theoretical work has been undertaken to describe the negative effects of Technical Debt, these studies tend to have a weak empirical basis and often lack quantitative data. The aim of this study is to estimate wasted time, caused by the Technical Debt interest during the software life-cycle. This study also investigates how practitioners perceive and estimate the impact of the negative consequences due to Technical Debt during the software development process. This paper reports the results of both an online web-survey provided quantitative data from 258 participants and follow-up interviews with 32 industrial software practitioners. The importance and originality of this study contributes and provides novel insights into the research on Technical Debt by quantifying the perceived interest and the negative effects it has on the software development life-cycle. The findings show that on average, 36% of all development time is estimated to be wasted due to Technical Debt; Complex Architectural Design and Requirement Technical Debt generates most negative effect; and that most time is wasted on understanding and/or measuring the Technical Debt. Moreover, the analysis of the professional roles and the age of the software system in the survey revealed that different roles are affected differently and that the consequences of Technical Debt are also influenced by the age of the software system.
Software engineering is a human activity. Despite this, human aspects are under-represented in te... more Software engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate. This study's objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Forty participants (N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures (r = 5) experiment (n = 200), a survey, and semi-structured interviews. The statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states. From the qualitative data, it is clear that technical debt activates a substantial portion of the
Process Debt, like Technical Debt, can be the source of short-term benefits but often is harmful ... more Process Debt, like Technical Debt, can be the source of short-term benefits but often is harmful in the long term for a software organization. Nonetheless, information about Process Debt is scarce in current literature. We conducted an exploratory study of Process Debt in four international organizations by interviewing 16 practitioners. The findings show that Process Debt can be a harmful phenomenon that needs attention and new practices, as it is different from Technical Debt. We provide an initial framework, composed by a definition and a conceptual model for Process Debt, showing types, causes, consequences, and debt accumulation patterns.
This is a PDF file of an article that has undergone enhancements after acceptance, such as the ad... more This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
Large software companies need to support continuous and fast delivery of customer value both in t... more Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both the evolution and maintenance of existing systems are hampered by Technical Debt. Although a lot of theoretical work on Technical Debt has been produced recently, its practical management lacks empirical studies. In this paper, we investigate the state of practice in several companies to understand what the cost of managing TD is, what tools are used to track TD, and how a tracking process is introduced in practice. We combined two phases: a survey involving 226 respondents from 15 organizations and an in-depth multiple case study in three organizations including 13 interviews and 79 Technical Debt issues. We selected the organizations where Technical Debt was better tracked in order to distill best practices. We found that the development time dedicated to managing Technical Debt is substantial (an average of 25% of the overall development), but mostly not systematic: only a few participants (26%) use a tool, and only 7.2% methodically track Technical Debt. We found that the most used and effective tools are currently backlogs and static analyzers. By studying the approaches in the companies participating in the case study, we report how companies start tracking Technical Debt and what the initial benefits and challenges are. Finally, we propose a Strategic Adoption Model for the introduction of tracking Technical Debt in software organizations.
Large Software Companies need to support the continuous and fast delivery of customer value in bo... more Large Software Companies need to support the continuous and fast delivery of customer value in both the short and long term. However, this can be impeded if the evolution and maintenance of existing systems is hampered by what has been recently termed Technical Debt (TD). Specifically, Architectural TD has received increased attention in the last few years due to its significant impact on system success and, left unchecked, it can cause expensive repercussions. It is therefore important to understand the underlying factors of architectural TD. With this as background, there is a need for a descriptive model to illustrate and explain different architectural TD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the architectural TD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the architectural TD phenomenon. This model categorizes the main characteristics of architectural TD and reveals their relations. The results show that, by using this model, different stakeholders could increase the system's success rate, and lower the rate of negative consequences, by raising awareness about architectural TD.
Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it i... more Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring of Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review of 557 unique papers published until 2019, following a consolidated methodology applied in software engineering. We included 44 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that Technical Debt prioritization research is preliminary and there is no consensus on what the important factors are and how to measure them. Consequently, we cannot consider current research
Uploads
Papers by Terese Besker