No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Practitioners' Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development
Abstract
Scientific software development refers to a specific branch of software engineering that targets the development of scientific applications. Such applications are usually developed by non-expert software engineers (e.g., natural scientists, biologists, etc.) and pertain to special challenges. One such challenge (stemming from the lack of proper software engineering background) is the low structural quality of the end software-also known as Technical Debt-leading to long debugging and maintenance cycles. To contribute towards understanding the software engineering practices that are used in scientific software development, and investigating whether their application can lead to preventing structural quality decay (also known as Technical Debt prevention); in this study, we seek insights from professional scientific software developers, through a questionnaire based empirical setup. The results of our work suggest that several practices (e.g., Reuse and Proper Testing) can prevent the introduction of Technical Debt in software development projects. On the other hand, other practices seem as either improper for TD prevention (e.g., Parallel / Distributed Programming), whereas others as non-applicable to the branch of scientific software development (e.g., Refactorings or Use of IDEs). The results of this study prove useful for the training plan of scientists before joining development teams, as well as for senior scientists that act as project managers in such projects.
... Yu reported a 34.5% coding fault reduction in the software release of Lucent Technologies' (a company name) 5ESS switching system issued after applying his fault prevention approach and the coding fault prevention guideline. Training programmers before their coding is still treated as one of the best practices for fault prevention as indicated in recent studies [12,51]. ...
... Developing the programmers' knowledge and skills can be helpful. They should be trained in good programming practices (e.g., information hiding and encapsulation) [51,61] and in the recognition and correction of actual errors [3]. The improvement of organisational software development process level, such as Capability Maturity Model Integration (CMMI) level 5 [40,62], can also achieve fault prevention effect. ...
... This is supported by the automation and incremental implementation principles for fault prevention as illustrated in Huizinga and Kolawa [65]. Automation for routine task is suggested as one of the best software engineering practices for scientific software development in [51] and mentioned frequently as one of the fault mitigation strategies related to processes by professional developers [12]. ...
Software faults are costly to find and remove from programs. It is better to avoid inserting the faults in the first place. The authors identify requirements‐related faults that can arise during the transformation of formal specifications into programs, analyse each to discover its causes, and propose corresponding fault prevention methods. The approach works by analysing a specification, decomposing it into specification fragments with different levels like components, determining the correct implementation order among the components, and enabling automated code generation for the components and other low‐level specification fragments. The approach seeks to reduce the faults in programs significantly by guiding programmers to work effectively and productively. The authors evaluate the approach's performance experimentally and compare it to the performance of a fault‐prevention method with industry applications.
... Arvanitou et al. [27] investigate how the accumulation of TD can be explained in (scientific) software development. To do that, authors first identify software engineering practices used to develop scientific software and the most common causes of introducing TD and then map them. ...
Background: Software companies must balance fast value delivery with quality, a trade-off that can introduce technical debt and potentially waste developers' time. As software systems evolve, technical debt tends to increase. However, estimating its impact on lead time still requires more empirical and experimental evidence. Objective: We conduct an empirical study investigating whether technical debt impacts lead time in resolving Jira issues. Furthermore, our aim is to measure the extent to which variance in lead time is explainable by the technical debt. Method: We conducted an industrial case study to examine the relationship in six components, each of which was analyzed individually. Technical debt was measured using SonarQube and normalized with the component's size, while lead time to resolve Jira issues was collected directly from Jira. Results: We found a set of mixed results. Technical debt had a moderate positive impact on lead time in two components, while we did not see a meaningful impact on two others. A moderate negative impact was found in the remaining two components. Conclusion: The findings show that technical debt alone can not explain all the variance in lead time, which ranges from 5% up to 41% across components. So, there should be some other variables (e.g., size of the changes made, complexity, number of teams involved, component ownership) impacting lead time, or it might have a residual effect that might manifest later on. Further investigation into those confounding variables is essential.
... Arvanitou et al. [27] investigate how the accumulation of TD can be explained in (scientific) software development. To do that, authors first identify software engineering practices used to develop scientific software and the most common causes of introducing TD and then map them. ...
Software development organisations aim to stay effective and efficient amid growing system complexity. To address this, they often form small teams focused on separate components that can be independently developed, tested, and deployed. Aligning architecture with organisational structures is crucial for effective communication and collaboration, reducing code and architectural degradation. Assigning specific component responsibility to the teams primarily working on them is key to these goals. This article explores the relationship between ownership and contribution alignment and code quality degradation, measured as technical debt per line of code. It also examines how team structure changes impact their ability to manage code quality degradation. We conducted a case study in a company developing a large software system, analysing ten components managed by one team. This team was later split into two, redistributing components between the new teams. Archival data from development tools used in their daily operations was collected. Before the split, there was a statistically significant negative correlation between contribution alignment and technical debt density in four components, indicating that higher contribution alignment leads to lower technical debt density and better code quality. After the split, this negative correlation persisted in three components, while five components showed a positive correlation, suggesting that low contribution alignment might worsen code quality degradation. Our findings suggest that contribution alignment is important in controlling code quality degradation in software development organisations. Ensuring teams are responsible for components they are most familiar with and minimising dependencies between teams can help mitigate code quality degradation.
... A key technical debt parameter that needs to be considered when managing technical debt is the notion of Principal, which is the number of code inefficiencies that have to be resolved in order for a given project to be in an optimum state in terms of maintainability [2]. Ensuring that a project retains an acceptable quality level-e.g., through imposing the use of quality gates for controlling the amount of introduced TD Principal [3]-can lead to smoother and more effective development, reducing the vicious cycles of technical debt accumulation [4]. Nevertheless, in practice, and due to tight development schedule, the quality of software tends to deteriorate along evolution [3]; whereas the same applies for TD Principal, in the sense that TD Principal seems to be increasing in subsequent versions, even for systems or ecosystems that are well-known for their levels of quality and software development processes (e.g., the Apache ecosystem-despite a decrease in some cases in the TD Principal density metric) [5]. ...
One of the most well-known laws of software evolution suggests that code quality deteriorates over time. Following this law, recent empirical studies have brought evidence that Technical Debt (TD) Principal tends to increase (in absolute value) as the system grows, since more technical debt issues are added than resolved over time. To shed light into how technical debt accumulation occurs in practice, in this paper we explore specific maintenance activities (i.e., feature addition, bug fixing, and refactoring) and explore the balance between the technical debt that they introduce or resolve. To achieve this goal, we rely on studying Pull Requests (PR), which are the most established way to contribute code to an open-source project. A Pull Request is usually comprised by more than one commits, corresponding to a specific development / maintenance activity. In our study, we categorized Pull Requests, based on their labels, to find the effect that the different maintenance activities have on the accumulation of technical debt across evolution. In particular , we have analysed more than 13.5K pull requests (mined from 10 OSS projects), by calculating the TD Principal (calcu-lated through SonarQube) before and after the Pull Requests. The results of the study suggested that several labels are used for tagging Pull Requests, out of which the most prevalent ones are new features, bug fixing, and refactoring. The effect of these activities on TD Principal accumulation is statistically different, and: (a) the addition of features tends to increase TD Principal; (b) refactoring is having an almost consistent positive effect (reducing TD Principal); and (c) bug fixing activity has undecisive impact on TD Principal. These results are compared to existing studies, interpreted, and various useful implications for researchers and practitioners have been drawn.
ContextStudying the causes of technical debt (TD) could aid in TD prevention, thus easing the job of TD management. On the other hand, better understanding of the effects of TD could also aid in TD management by facilitating more informed decisions about incurring and paying off debt.Objective
Create a deeper understanding, and confirming existing evidence, of the causes and effects of TD by collecting new evidence from real-world TD examples.Method
InsighTD is a globally distributed family of industrial surveys on the causes and effects of TD. It is designed to run as a large-scale study based on continuous and independent replications in different countries. The survey instrument asks practitioners to describe in detail a real example of TD from their experience. We present in this paper the design of InsighTD, which has the primary goal of replication at a large-scale, with the results of the study in Brazil as a small part of the larger puzzle.ResultsThe first iteration of the InsighTD survey, carried out in Brazil, yielded 107 responses. We identified a total of 78 causes and 66 effects, which confirm and also extend the current knowledge on causes and effects of TD. Then, we organized the identified set of causes and effects in probabilistic cause-effect diagrams. The proposed diagrams highlight the causes that can most contribute to the occurrence of TD as well as the most common effects that occur as a result of debt.Conclusion
We intend to reduce the problem of isolated TD investigations that are not yet representative and build a continuous and generalizable empirical basis for understanding practical problems and challenges of TD.
This report documents the program and outcomes of Dagstuhl Seminar 16162, “Managing Technical Debt in Software Engineering.” We summarize the goals and format of the seminar, results from the breakout groups, a definition for technical debt, a draft conceptual model, and a research road map that culminated from the discussions during the seminar. The report also includes the abstracts of the talks presented at the seminar and summaries of open discussions.
Technical debt (TD) is a metaphor for taking shortcuts or workarounds in technical decisions to gain short-term benefit in time-to-market and earlier software release. In this study, one large software development organization is investigated to gather empirical evidence related to the concept of technical debt management (TDM). We used the exploratory case study method to collect and analyze empirical data in the case organization by interviewing a total of 25 persons in eight software development teams. We were able to identify teams where the current strategy for TDM was only to fix TD when necessary, when it started to cause too much trouble for development. We also identified teams where the management had a systematic strategy to identify, measure and monitor TD during the development process. It seems that TDM can be associated with a similar maturity concept as software development in general. Development teams may raise their maturity by increasing their awareness and applying more advanced processes, techniques and tools in TDM. TDM is an essential part of sustainable software development, and companies have to find right approaches to deal with TD to produce healthy software that can be developed and maintained in the future.
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.
Background
The development of scientific software applications is far from trivial, due to the constant increase in the necessary complexity of these applications, their increasing size, and their need for intensive maintenance and reuse.
Aim
To this end, developers of scientific software (who usually lack a formal computer science background) need to use appropriate software engineering (SE) practices. This paper describes the results of a systematic mapping study on the use of SE for scientific application development and their impact on software quality.
Method
To achieve this goal we have performed a systematic mapping study on 359 papers. We first describe a catalog of SE practices used in scientific software development. Then, we discuss the quality attributes of interest that drive the application of these practices, as well as tentative side-effects of applying the practices on qualities.
Results
The main findings indicate that scientific software developers are focusing on practices that improve implementation productivity, such as code reuse, use of third-party libraries, and the application of “good” programming techniques. In addition, apart from the finding that performance is a key-driver for many of these applications, scientific software developers also find maintainability and productivity to be important.
Conclusions
The results of the study are compared to existing literature, are interpreted under a software engineering prism, and various implications for researchers and practitioners are provided. One of the key findings of the study, which is considered as important for driving future research endeavors is the lack of evidence on the trade-offs that need to be made when applying a software practice, i.e., negative (indirect) effects on other quality attributes.
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.
Introduction Design of the Case Study Data Collection Data Analysis Reporting and Dissemination Lessons Learned
Nearly two decades ago, Ward Cunningham introduced us to the term "technical debt" as a means of describing the long term costs associated with a suboptimal software design and implementation. For most programs, especially those with a large legacy code baseline, achieving zero absolute debt is an unnecessary and unrealistic goal. It is important to recall that a primary reason for managing and eliminating debt is to drive down maintenance costs and to reduce defects. A sufficiently low, manageable level of debt can minimize the long-term impact, i.e., "low debt interest payments". In this article, we define an approach for establishing program specific thresholds to define manageable levels of technical debt.
The AUTOSPEC system is an automatic motor specification software system that primarily serves to non-interactively produce bill of materials from sales orders. At the core, the system applies Expert System and coordinated Relational Database technology ...
Can Clean New Code Reduce Technical Debt Density?
- G Digkas
- A Chatzigeorgiou
- A Ampatzoglou
- P Avgeriou
Digkas, G., Chatzigeorgiou, A., Ampatzoglou, A. and
Avgeriou, P. (2022). Can Clean New Code Reduce
Technical Debt Density? Transactions on Software Engineering, IEEE Computer Society.
Architecture technical debt: Understanding causes and a qualitative model. 40 th EUROMICRO Conference on Software Engineering and Advanced Applications
- A Martini
- J Bosch
- M Chaudron
Martini, A., Bosch, J. and Chaudron, M. (2014). Architecture technical debt: Understanding causes and a qualitative model. 40 th EUROMICRO Conference on Software Engineering and Advanced Applications. pp. 85-92.