Content uploaded by Terese Besker
Author content
All content in this area was uploaded by Terese Besker on Jun 15, 2018
Content may be subject to copyright.
A preview of the PDF is not available
Technical Debt Cripples Software Developer Productivity - A longitudinal study on developers’ daily software development work
Abstract and Figures
Software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, software development can be impeded by what has been described as Technical Debt (TD). The aim of this study is to explore the negative consequences of TD in terms of wasted software development time. This study also investigates on which additional activities this wasted time is spent and whether different types of TD impact the wasted time differently. This study also sets out to examine the benefits of tracking and communicating the amount of wasted time, both from a developer’s and manager’s perspective. This paper reports the results of a longitudinal study, surveying 43 software developers, together with follow-up interviews with 16 industrial software practitioners. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to TD and that they are frequently forced to introduce new TD due to already existing TD. The most common activity on which additional time is spent is performing additional testing.
Figures - uploaded by Terese Besker
Author content
All figure content in this area was uploaded by Terese Besker
Content may be subject to copyright.
... Source code duplication by copying and pasting into another section of source code, even with minor modification, often happens throughout software development and maintenance. It can result from lacking development skills or rushed development, prioritizing visible profit in the form of new feature delivery over less visible code quality [1]. This copied code is called code clone, and the process is called code cloning [2][3][4]. ...
The growing popularity of enterprise technologies for decentralized systems leads to commonalities in using components. This direction, however, opens new challenges to code clone detection. Approaches can no longer look at the low-level code but must deal with the higher-level component semantics. Yet, not many works addressed this trend. One of the quality issues that can be identified in large systems is duplicated behavior with different syntactic structures. It is crucial to detect these issues for enterprises where software’s codebase(s) grows and evolves, and maintenance costs rise significantly. This issue is referred to as a semantic clone. The detection of semantic clones requires semantic information about the given program. Unfortunately, while many code clone detection techniques are proposed, there is a lack of solutions targeted explicitly toward enterprise systems and even fewer solutions dedicated to semantic clones. To reason about semantic clones, we consider different pairs of component call-graphs in the system. Since different component types are common in enterprise systems, we can ensure that only relevant fragments are matched, using targeted enterprise metadata. When applied to an established system benchmark, our method indicates high accuracy in detecting semantic clones. We also assessed different system versions to elaborate on the method’s applicability to decentralized system evolution.
... É reconhecida como um problema crítico no setor de desenvolvimento de software atual e, caso não seja verificada, a DT pode causar grandes excedentes de custos, ou seja, gerando grandes custos de manutenção devido a problemas internos de qualidade e a incapacidade de adicionar novas alterações ao sistema, podendo levar a um ponto de crise em que é necessário realizar uma refatoração grande e muito cara ou até uma substituição completa do software. (Besker et al., 2018). ...
Cada vez mais tem sido adotado a metodologia ágil para desenvolvimento de software. Contudo, pouca informação sobre aplicação de processos e práticas das metodologias ágeis acabam por repercutir em Dívida Técnica (DT). Este estudo tem como objetivo detectar a compreensão dos profissionais de desenvolvimento de software sobre DT no desenvolvimento ágil. Este estudo é de natureza aplicada com abordagem quantitativa através de pesquisa exploratória, a coleta de dados foi aplicação de questionário online seguida de análise estatística. Amostragem foi não probabilística com 33 respondentes, pode-se observar que os profissionais apresentam diferentes motivos para a ocorrência de DT. Detectou-se também que não há cultura organizacional. Este estudo propõe o Portal do conhecimento e o Café do Conhecimento para disseminar experiências entre profissionais.
... Besker et al. (2019) studied the strategies to prioritize the identified TDs to be resolved and the most important factors affecting this process. Besker et al. (2018) carried out another study to determine the refactoring cost and negative effects of different types of TD. Besides, there have been various tools for identifying TDs. ...
Quantum computing is a rapidly growing field attracting the interest of both researchers and software developers. Supported by its numerous open-source tools, developers can now build, test, or run their quantum algorithms. Although the maintenance practices for traditional software systems have been extensively studied, the maintenance of quantum software is still a new field of study but a critical part to ensure the quality of a whole quantum computing system. In this work, we set out to investigate the distribution and evolution of technical debts in quantum software and their relationship with fault occurrences. Understanding these problems could guide future quantum development and provide maintenance recommendations for the key areas where quantum software developers and researchers should pay more attention. In this paper, we empirically studied 118 open-source quantum projects, which were selected from GitHub. The projects are categorized into 10 categories. We found that the studied quantum software suffers from the issues of code convention violation, error-handling, and code design. We also observed a statistically significant correlation between code design, redundant code or code convention, and the occurrences of faults in quantum software.
Technical debt represents unwanted issues that result from decisions made to speed up the design or implementation of software at the expense of resolving existing issues. Like financial debt, it consists of the principal and an interest. Debt is usually paid back through code rewrites, refactoring, or the introduction of test code. When unchecked, interest can accumulate over time and lead to development crises where focus and resources must be shifted to resolve existing debt before the development process can be resumed. Existing software tooling allows practitioners to quantify the level of debt and identify its sources, allowing decision makers to measure and control it. We propose a detailed exploration of the characteristics of source code technical debt over the lifetime of several popular open-source applications. We employed a SonarQube instance configured for longitudinal analysis to study all publicly released versions of the target applications, amounting to over 15 years’ worth of releases for each. We found that a small number of issue types were responsible for most of the debt and observed that refactoring reduced debt levels across most application packages. We observed increased variance in technical debt distribution and composition in early application versions, which lessened once applications matured. We addressed concerns regarding the accuracy of SonarQube estimations and illustrated some of its limitations. We aim to continue our research by including additional tools to characterize debt, leverage existing open data sets and extend our exploration to include additional applications and types of software.KeywordsTechnical debtSoftware evolutionLongitudinal case studyOpen-source softwareRefactoringSoftware maintenance
Context:
Technical Debt (TD) is a term for software solutions that are beneficial in the short-term but impede future change.
Goal:
Previous research on TD indicates various management-related causes. We analyze the perspective of IT managers on TD since they usually have a major influence on deadlines, the project’s budget, and setting up a TD management (TDM) process.
Method:
To determine the IT managers’ perspective, we obtained and analyzed data from 16 semi-structured interviews and a three-person focus group discussion.
Results:
We found that all IT managers understood the TD concept. They consider TDM to be an essential topic, though nearly none of them had set up a TDM process so far. We identified three major concerns the IT managers had regarding TDM: communicating about TD, establishing a TDM process, and dealing with vintage systems, i.e., old legacy systems We developed a model specifying causes and consequences visible to business stakeholders, causal chains, and vicious cycles.
Conclusions:
Our research identifies new research gaps and demonstrates to practitioners that investing in a TDM process may be beneficial. It provides the V4CTD model of Visibility, Cycles & Chains of Causes & Consequences of TD, extending the TD conceptual model and facilitating communication on TD with business stakeholders.
Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.
Context: Contemporary software development is typically conducted in dynamic, resource-scarce environments that are prone to the accumulation of technical debt. While this general phenomenon is acknowledged, what remains unknown is how technical debt specifically manifests in and affects software processes, and how the software development techniques employed accommodate or mitigate the presence of this debt.
Objectives: We sought to draw on practitioner insights and experiences in order to classify the effects of agile method use on technical debt management, given the popularity and perceived success of agile methods. We explore the breadth of practitioners’ knowledge about technical debt; how technical debt is manifested across the software process; and the perceived effects of common agile software development practices and processes on technical debt. In doing so, we address a research gap in technical debt knowledge and provide novel and actionable managerial recommendations.
Method: We designed, tested and executed a multi-national survey questionnaire to address our objectives, receiving 184 responses from practitioners in Brazil, Finland, and New Zealand.
Results: Our findings indicate that: 1) Practitioners are aware of technical debt, although, there was under utilization of the concept, 2) Technical debt commonly resides in legacy systems, however, concrete instances of technical debt are hard to conceptualize which makes it problematic to manage, 3) Queried agile practices and processes help to reduce technical debt; in particular, techniques that verify and maintain the structure and clarity of implemented artifacts (e.g., Coding standards and Refactoring) positively affect technical debt management.
Conclusions: The fact that technical debt instances tend to have characteristics in common means that a systematic approach to its management is feasible. However, notwithstanding the positive effects of some agile practices on technical debt management, competing stakeholders’ interests remain a concern.
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 companies need to produce high-quality software and support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered by compromised software quality attributes that have an important influence on the overall software development lifecycle. The aim of this study is threefold: to understand which quality issues have the most negative impact on the software development lifecycle process, to determine the association of these quality issues in relation to the age of the software, and relate each of these quality issues to the impact of different Technical Debt types. This paper reports the results of six initial group interviews with in total 43 practitioners, an online web-survey provided quantitative data from 258 participants and seven follow-up group interviews with in total 32 industrial software practitioners. First, this study shows that practitioners identified maintenance difficulties, a limited ability to add new features, restricted reusability, and poor reliability, and performance degradation issues as the quality issues having the most negative effect on the software development lifecycle. Secondly, we found no evidence for the generally held view that the Technical Debt increases with age of the software. Thirdly, we show that Technical Debt affects not only productivity but also several other quality attributes of the system.
Software companies need to produce high-quality software and support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered by compromised software quality attributes that have an important influence on the overall software development lifecycle. The aim of this study is threefold: to understand which quality issues have the most negative impact on the software development lifecycle process, to determine the association of these quality issues in relation to the age of the software, and relate each of these quality issues to the impact of different Technical Debt types. This paper reports the results of six initial group interviews with in total 43 practitioners, an online web-survey provided quantitative data from 258 participants and seven follow-up group interviews with in total 32 industrial software practitioners. First, this study shows that practitioners identified maintenance difficulties, a limited ability to add new features, restricted reusability, and poor reliability, and performance degradation issues as the quality issues having the most negative effect on the software development lifecycle. Secondly, we found no evidence for the generally held view that the Technical Debt increases with age of the software. Thirdly, we show that Technical Debt affects not only productivity but also several other quality attributes of the system.
Context: Since software development is a complex socio-technical activity that involves coordinating different disciplines and skill sets, it provides ample opportunities for waste to emerge. Waste is any activity that produces no value for the customer or user.
Objective: The purpose of this paper is to identify and describe different types of waste in software development.
Method: Following Constructivist Grounded Theory, we conducted a two-year five-month participant-observation study of eight software development projects at Pivotal, a software development consultancy. We also interviewed 33 software engineers, interaction designers, and product managers, and analyzed one year of retrospection topics. We iterated between analysis and theoretical sampling until achieving theoretical saturation.
Results: This paper introduces the first empirical waste taxonomy. It identifies nine wastes and explores their causes, underlying tensions, and overall relationship to the waste taxonomy found in Lean Software Development.
Limitations: Grounded Theory does not support statistical generalization. While the proposed taxonomy appears widely applicable, organizations with different software development cultures may experience different waste types.
Conclusion: Software development projects manifest nine types of waste: building the wrong feature or product, mismanaging the backlog, rework, unnecessarily complex solutions, extraneous cognitive load, psychological distress, waiting/multitasking, knowledge loss, and ineffective communication.
Many social science studies are based on coded in-depth semistructured interview transcripts. But researchers rarely report or discuss coding reliability in this work. Nor is there much literature on the subject for this type of data. This article presents a procedure for developing coding schemes for such data. It involves standardizing the units of text on which coders work and then improving the coding scheme’s discriminant capability (i.e., reducing coding errors) to an acceptable point as indicated by measures of either intercoder reliability or intercoder agreement. This approach is especially useful for situations where a single knowledgeable coder will code all the transcripts once the coding scheme has been established. This approach can also be used with other types of qualitative data and in other circumstances.
A known problem in large software companies is to balance the prioritization of short-term and long-term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi-phase, multiple-case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra-activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises.
The technical debt metaphor is widely used to encapsulate numerous software quality problems. The metaphor is attractive to practitioners as it communicates to both technical and nontechnical audiences that if quality problems are not addressed, things may get worse. However, it is unclear whether there are practices that move this metaphor beyond a mere communication mechanism. Existing studies of technical debt have largely focused on code metrics and small surveys of developers. In this paper, we report on our survey of 1,831 participants, primarily software engineers and architects working in long-lived, software-intensive projects from three large organizations, and follow-up interviews of seven software engineers. We analyzed our data using both nonparametric statistics and qualitative text analysis. We found that architectural decisions are the most important source of technical debt. Furthermore, while respondents believe the metaphor is itself important for communication, existing tools are not currently helpful in managing the details. We use our results to motivate a technical debt timeline to focus management and tooling approaches.
Qualitative Data is meant for the novice researcher who needs guidance on what specifically to do when faced with a sea of information. It takes readers through the qualitative research process, beginning with an examination of the basic philosophy of qualitative research, and ending with planning and carrying out a qualitative research study. It provides an explicit, step-by-step procedure that will take the researcher from the raw text of interview data through data analysis and theory construction to the creation of a publishable work. The volume provides actual examples based on the authors' own work, including two published pieces in the appendix, so that readers can follow examples for each step of the process, from the project's inception to its finished product. The volume also includes an appendix explaining how to implement these data analysis procedures using NVIVO, a qualitative data analysis program.