Conference Paper

Practitioners' Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development

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

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.

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 authors.

ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
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.
Article
Full-text available
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.
Article
Full-text available
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.
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
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.
Article
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.
Book
Introduction Design of the Case Study Data Collection Data Analysis Reporting and Dissemination Lessons Learned
Article
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.
Article
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.