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.
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
... Architecture smells help reveal technical debt items; structures that provide short-term advantages but impede software development and maintenance in the long run [5]. Architectural technical debt focuses on higher-level problems and was identified as one of the most dangerous types of technical debt [6] because there is a lack of refactoring strategies enabling repayment [7]. Architecture maintainability smells, or maintainability smells (MS), are architecture smells specifically impacting maintainability. ...
... Using a full-text search, we searched for references that mentioned at least one architecture smell name. We excluded references that only discussed code or design smells (33), were unrelated to architecture smells (120), had no concrete architecture smell names mentioned (60), or solely focused on architecture smells related to other quality attributes (7). The numerous references not addressing architectural smells can be attributed to the ambiguous term "hotspot pattern" used for data throughput. ...
... Yet, the drive for rapid feature development often undermines long-term architectural integrity, leading to technical and architectural debt (Besker et al., 2018;Martini et al., 2018;Das et al., 2022;Azadi et al., 2019;Fontana et al., 2016;Haendler et al., 2017), where quick fixes harm future maintainability and scalability. ...
... These wastes reduce efficiency, increase costs, and may produce unsatisfactory results [25]. Organisations may restructure their operations, cut costs, increase productivity, and produce higher-quality software products more effectively by recognising and eliminating these software development wastes [26]. [27] to adapt to Lean Thinking and the Toyota Production System from manufacturing to software development. ...
... Longitudinal approaches to TD also included the study described in [7]. It presents an empirical approach based on surveys and interviews that concluded that on average, almost a quarter of development time was wasted to technical debt and that existing debt often introduced additional TD. ...
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
... 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.
Context and Motivation – Developer eXperience (Dev-X) is a recent research area that focuses on developers perceptions, feelings, and values with respect to software development and software quality. Research suggests that factors and practices related to Dev-X can have a substantial impact on developer productivity (Dev-P). However, despite a large and diverse body of literature on factors that can impact Dev-P in general, there is no coherent and comprehensive characterization of how Dev-X-specific insights can influence developer productivity.
Aims – In the presented research, we aim to provide a coherent, comprehensive characterization of factors and practices related to Dev-X, with a particular focus on those factors and practices that potentially affect Dev-P.
Method – To this end, we performed a systematic literature review and identified 218 relevant papers in this area. We characterize the papers based on the related frameworks, and concepts common to Dev-X and Dev-P as presented in the existing literature. Dev-X factors such as ’work fragmentation’ and practices such as ’collaboration with owner-developer’ are identified using a grounded-in-the-literature, content-analysis method, guided by the theory. For each Dev-X factor, we identify attributes that might be used to assess/measure the current status (of an organisation or project) regarding that factor and how that factor and its effects on productivity have been evidenced in the literature (mentioned vs. considered in questionnaires vs. substantiated with a more positivist evaluation).
Results – We identify 33 Dev-X-related factors and 41 Dev-X-related practices which are organized into ten themes to summarize their influence. The results suggest that the availability of required resources, relevant expertise re the allocated tasks, and fewer interruptions are among the top positively impacting factors. Conversely, factors like code complexity, heterogeneous contexts of tasks, and non-adherence to standardization harm Dev-X and Dev-P. Top industrial practices employed to mitigate the negative influence of factors include characterization-based task assignments, mental model support, and the timely evolution of technologies.
Conclusions – Overall, this research suggests that organizations can influence Dev-P through improved Dev-X, incorporating suitable practices to mediate relevant factors in their context. Important in this regard are practices like fragmenting large tasks, highlighting the utility of proposed tasks/changes to the developers, and promoting (developer) ownership of artefacts. Finally, our results point to areas where further research seems appropriate, i.e., where Dev-X factors/practices have been proposed as being impactful on Dev-P but not yet fully substantiated or explored as such (factors like ‘Nature of Activity’ and practices like choosing practices/protocols appropriately).
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.