Practitioners’ Perspective on Practices for Preventing Technical Debt
Accumulation in Scientific Software Development
Elvira-Maria Arvanitou, Nikolaos Nikolaidis, Apostolos Ampatzoglou and Alexander Chatzigeorgiou
Department of Applied Informatics, University of Macedonia, Greece
Keywords: Software Engineering Practice, Technical Debt, Scientific Software Development, Prevention.
Abstract: Scientific software development refers to a specific branch of software engineering that targets the develop-
ment 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 under-
standing 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 pre-
vention); in this study, we seek insights from professional scientific software developers, through a question-
naire-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.
Scientific software development refers to the end-to-
end (from requirements analysis to deployment and
maintenance) construction lifecycle of software ap-
plications used for scientific purposes (e.g., physics,
biology, medical analysis, and data science). The ne-
cessity for developing scientific software has
emerged due to the need for continuous experimenta-
tion and validation of research outcomes (e.g., simu-
lations, or cases studies) before the publication of re-
sults (Birdsall and Langdon, 1991). Nevertheless,
such a continuous experimentation leads to continu-
ous maintenance (i.e., small incremental develop-
ments, debugging, and bug fixing cycles); which, by
considering the usually long execution time of such
software (in the common case executed upon big
data), can lead to long delays in the scientific process,
if maintenance is not successful.
During the last decade, in traditionalsoftware
engineering, the term Technical Debt (TD) (Cunning-
ham, 1992) has emerged so as to capture the effi-
ciency of maintenance process, both in terms of im-
proving the maintainability of the software, as well
as, of costs occurring due to low maintainability of
software (Avgeriou et. al., 2016). In every system, the
accumulation of TD is inevitable, since the develop-
ment of zero-TD systems is not financially viable;
and therefore: non-realistic (Eisenberg, 2012). Con-
sequently, the TD that is accumulated in a software
system needs to somehow be controlled, so as to re-
duce its negative impacts. In the literature, two TD
reduction methods have been introduced: TD repay-
ment (e.g., through refactoring) (Li et al., 2015) and
TD prevention (e.g., through writing clean new code)
(Digkas et al., 2022). By contrasting the two options,
TD prevention seems more fitting for the domain of
scientific software development, since: (a) dedicated
refactoring sessions are not usual in this context; (b)
there is limited refactoring support for the most com-
mon programming languages in the field (usually
non-OO languages); and (c) scientific software is usu-
ally developed by scientists, without a strong back-
ground in software development—refactoring might
be a non-trivial task for them.
Based on the above, in this paper we aim to em-
pirically understand and discuss how TD accumula-
Arvanitou, E., Nikolaidis, N., Ampatzoglou, A. and Chatzigeorgiou, A.
Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development.
DOI: 10.5220/0010995000003176
In Proceedings of the 17th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2022), pages 282-291
ISBN: 978-989-758-568-5; ISSN: 2184-4895
2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
tion could be prevented in the field of scientific soft-
ware development. To achieve this goal, we: (a) seek
for Software Engineering (SE) practices that are used
while developing scientific software; (b) identify the
most common causes of introducing TD; and (c)
search for a mapping between the two. For identifying
SE practices relevant to the scientific software devel-
opment community, we refer to a very recent second-
ary study in the field conducted by Arvanitou et al.
(2021); whereas for spotting potential causes of TD
accumulation, we refer to the outcomes of the In-
sighTD project
(Rios et al., 2020). Given the above,
our main contribution is the exploration of which SE
practices applied in scientific software development
can be used for preventing TD accumulation”.
To achieve this goal, we have performed a ques-
tionnaire-based study on 5 scientific software devel-
opment organizations, aiming at understanding: (a)
which SE practices the developers are familiar with;
(b) which SE practices they use more often; and (c)
which causes of TD accumulation can be hindered by
applying each practice. Obtaining the aforementioned
knowledge can advance scientific software develop-
ment practice, since: (a) it can guide the necessary
SE-related training of scientists before joining devel-
opment teams; (b) it can help senior scientists playing
the role of the project managers on which SE prac-
tices they need to impose in their development teams;
and (c) it can contribute towards the development of
an SE culture and a TD awareness in the community,
by noting the causes of TD accumulations and how
they can be prevented.
The rest of the paper is organized as follows: in
Section 2 we provide all necessary background infor-
mation to understand the main concepts of this study:
(a) the SE practices used in scientific software devel-
opment; and (b) the root causes of TD accumulation.
Next, in Section 3 we describe the setup of the con-
ducted empirical study; whose results we present in
Section 4. In Section 5, we provide a discussion based
of the results, aiming to deliver the main contribution
of this work: i.e., how TD accumulation can be pre-
vented in the scientific software development com-
munity. In Section 6, we discuss tentative threats to
validity, and in Section 7 we conclude the paper.
In this section, we present the necessary required
background information to establish a better under-
standing of this paper. To this end, in Section 2.1 we
present the SE practices that we have explored,
whereas in Section 2.2 the causes that can lead to TD
accumulation that can be considered for prevention
2.1 Software Engineering Practices for
Scientific Software Development
In this section, we present the most common SE prac-
tices for scientific software development, based on
the literature. More specifically, Arvanitou et al.
(2021) performed a mapping study to investigate the
current state-of-research and –practice on the use of
SE practices in scientific software development. Ta-
ble 1 presents the top-25 most used SE practices ap-
plied in this domain and the definition of each prac-
tice (Arvanitou et al., 2021).
Table 1: Top-25 Software Practices.
Practice Definition
Reuse of
Use pieces of software (packaged in the
form of a library) in software systems, other
than the one that they have been originally
developed for. This practice is expected to
lower testing effort and improve develop-
Use of API Use of a set of predetermined available
functionalities, available through a protocol
that allows two applications or services to
communicate with each other. Similarly to
before, this practice can reduce bugs and in-
MDE Focuses on the construction of a software
model (e.g., a diagram that specifies how
the software system should work) which is
automatically transformed to code. MDE
improves the ability of novice developers to
produce code by handling more high-level
Use of predefined generic program building
blocks for frequently occurring computa-
tion patterns (e.g., data-parallel map, re-
duce, scan, stencil) for which efficient plat-
form-specific implementations exist. Ex-
pected to improve performance of the appli-
AOP A programming paradigm that aims to in-
crease modularity by allowing the separa-
tion of cross-cutting concerns.
OOP A programming paradigm based on the
concept of objects, containing data and
methods. OOP introduces various benefits,
the most prominent one being the organiza-
tion of code to entities and actions, simi-
larly to the human perception.
Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development
Table 1: Top-25 Software Practices (Cont.).
Practice Definition
The ability to schedule when a task will start
and stop. The approach is used in software
development, mostly in terms of increasing
fault tolerance.
A programming paradigm that enables the
simultaneous execution of multiple instruc-
tions to speed-up the solution of a computa-
Any method that can be used for making the
software development process more effi-
cient, e.g., speed-up the development pro-
cess, producing software with less faults,
CBSE An approach that focuses on the design and
development of computer-based systems
with the use of reusable software compo-
nents. These components are usually ac-
quired off-the-shelf and are reused through
their public API. This practice is expected to
lower testing effort and improve develop-
ment Frame-
A software providing generic functionality,
which is accompanied by additional user-
written code, can provide application-spe-
cific software. Frameworks may include li-
braries, compilers, toolsets, and APIs. Simi-
larly to before, the use of frameworks re-
duces faults and speeds-up development.
Testing Approaches that check if the actual imple-
mentation of the software matches the ex-
pected requirements. The outcome of such
approaches is the identification of defects,
efore the software becomes o
The process through which the outcomes of
various development phases are specified in
documents. The usual artifacts produced are
models (diagrams or texts) that describe how
the system is expected to be developed. Such
models enable the understanding of code
structure, reducing the time required to un-
derstand code while maintaining the system.
A procedure that aims at ensuring the quality
of software products or services provided to
the customers by an organization. When
quality assurance focuses on maintainabil-
, the TD
ower is obvious.
An approach that focuses on the quantifica-
tion of quality aspects of the product, pro-
cess, and project (e.g., size, complexity, test
coverage). The use of metrics can help in: (a)
monitor the trend of software quality; (b)
compare tentative solutions for reuse; and
(c) identify spots in the code that might be
suboptimal in terms of quality.
TDD A software development approach in which
test cases are developed before coding, so as
to s
and validate what the code will do.
TDD ensures that are test are passed before
the operation of the software, reducing the
chance of facing bugs while executing the
CI / CD A development approach in which the engi-
neer automates the integration of code
changes from multiple contributors into a
single software project. Such processes sup-
port automated testing, building, and de-
loyment of the solutions.
A software development approach in which
two programmers work together at one
workstation (one screen, keyboard and
mouse among the pair) so as to increase
early fault identification and reduce devel-
opment delays.
Refactoring A technique for changing an existing code,
altering its internal structure without chang-
ing its external behavior. Refactoring is the
most common wa
for re
Pattern Well-known and established in practice so-
lutions to a commonly occurring problem in
software design or coding. Also applicable
to architecture, as well as for guaranteeing
specific qualities: security, or low memory
A software suite that enables programmers
to consolidate the different aspects of writ-
ing a computer program. Advanced IDEs
provide various kinds of assistance, such as
autocomplete, refactoring, automatic styl-
ing, etc.
DSL A programming language with a higher level
of abstraction optimized for a specific class
of problems. Such languages are closer to
the domain and boost productivity; never-
theless, their
eneric use is limited.
The automated synthesis of software assets,
such as documentation or models, to pro-
duce code. Code generation can speed-up
development and enable more novice devel-
ers to
roduce code.
An application that helps people working on
a common task to succeed in their goals. The
most known example of this category is col-
laborative source code development (e.g.,
with Git). Speeds-up development and eases
A set of commands, instructions, and other
syntax is used to create a software program.
Some languages (e.g., C, C++, Java, R, and
Python) are proven as more fitting for scien-
tific software develo
2.2 TD Prevention Causes
In this section, we present the most common causes
of TD based on the literature. As explained by Rios et
al. (2020), this list can help development teams to
ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering
identify actions that could prevent the introduction of
TD items in the first place. Thus, it is worthwhile to
understand the causes that could lead a development
team to accumulate TD, and propose mitigation ac-
tions as prevention measures. The four studies that are
dealing with identifying possible causes of TD accu-
mulation are outlined below.
Martini et al. (2014) performed a multiple-case em-
bedded study in seven sites at five large organizations
to investigate the current causes for the accumulation
of architectural TD (ATD). As a result of this study,
the authors provided a taxonomy of causes and their
influence in the accumulation of ATD. In addition,
Martini and Bosch (2017) conducted a case study in
order to investigate (a) the most dangerous ATD
items in terms of effort paid later; (b) the effects trig-
gered by such ATD items; and (c) if there are soci-
otechnical patterns of events that trigger the creation
of ATD. The results suggested that TD items can be
contagious, causing other parts of the system to be
contaminated with the same problem, which may lead
to nonlinear growth of interest. The authors also pre-
sented a model of ATD effects that can be used for
TD repayment prioritization.
Yli-Huumo et al. (2016) performed a case study
to investigate the role of technical debt management
in software development. In particular, the goal of
this study was to explore the causes of TD accumula-
tion, as well as its effects, and the strategies that are
being used for technical debt management. The re-
sults of this study suggested that the reasons for in-
curring TD were management decisions that were
made in order to reach deadlines, or unknowingly due
to lack of knowledge.
Finally, as a more recent work in this area, Rios
et al. (2020) conducted an industrial survey in differ-
ent countries in order to investigate the trends in the
TD area including the causes and the effects of TD.
107 practitioners from 11 countries joined in the sur-
vey. The results of this study suggested that most of
the practitioners were familiar with the concept of
TD. As a final outcome Rios et al. (2020) identified
78 causes that lead to TD occurrence. Out of them,
we focus on the most cited causes that lead to the ac-
cumulation of TD. According to Rios et al. (2020),
the most cited causes of TD are presented below:
Deadline—A certain period of time defined by
the team, project manager and / or customer to de-
liver a determined activity, feature or product. Ex-
ample: “The rush of managers (customers) that
want to receive something working asap”;
Inappropriate PlanningRefers to problems in
the planning of software development activities,
treated as a project. Example: “Lack of prioritiza-
tion of activities”;
Lack of Knowledge—Refers to lack of
knowledge about specifications of the project, the
unfamiliarity with any activity or artifact of the
project, and the usage, the operation or the pur-
pose of a particular technology. Example: “Lack
of testing knowledge in team”;
Lack of Defined Development ProcessRefers
to the lack of a sustainable methodology aimed at
creating and maintaining guides that would in-
crease the productivity of the software develop-
ment software team. Example: “Lack of a fol-
lowed processes”;
Lack of Tests—Means that the project has not
been tested at all, or that the testing is not suffi-
cient—not covering all requirements. Example:
“Lack of (functional) testing”
Ineffective Project ManagementRefers to in-
adequate management during the complete soft-
ware development lifecycle. Example: “Not fol-
lowing planning
Lack of Qualified ProfessionalsOccurs when
unprepared professionals perform a certain activ-
ity or because of lack of professionals prepared to
carry it out. Example: “Absence of specialist to
carry out specific activities”;
Lack of Experience— Refers to the lack of expe-
rience, obtained through the practice in certain
software development activities. Example: “Lack
of experience of programmers”;
Outdated or Incomplete Documentation—Oc-
curs when software documentation is outdated,
unfinished, or simply missing in the software pro-
ject. Example: “Incomplete documentation”;
Lack of Commitment Non-professional com-
mitment of stakeholders (usually software engi-
neers) to fulfil the tasks assigned to them along the
whole software development lifecycle. Example:
“Stakeholders not engaged”;
Poor Design Refers to poorly designed project,
suffering from example from high coupling. Ex-
ample: “Poorly designed database structure”.
The case study reported in this section was executed
as part of the EXA2PRO project
. EXA2PRO was an
Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development
EU-funded FET project aiming (among other) to ex-
plore the potential of applying TDM approaches in
High Performance Computing, and cultivate a struc-
tural quality culture in corresponding development
teams. The study was designed and is reported, based
on the guidelines by Runeson et al. (2012).
3.1 Research Objectives / Questions
The goal of this study expressed in terms of the Goal-
Question-Metric (GQM) approach (Basili, 1992) is
formulated as follows: analyze the software engi-
neering (SE) practices for the purpose of character-
ization with respect to their ability to prevent the ac-
cumulation of technical debt; as well as their useful-
ness (acquaintance of developers with them and ap-
plicability in scientific software development) from
the point of view of scientists that develop software”.
Based on this, we have derived three RQs:
: How familiar are the scientists that develop
scientific software to SE practices?
: How often do practitioners use SE practices?
: Can the use of SE practices prevent the accu-
mulation of TD?
The answer of the RQ
aims to identify the current
knowledge of scientists that develop scientific soft-
ware on SE practices. The answer to this research
question will shed light on the usefulness of the SE
practices, in the sense that practices to which the sci-
entists are not familiar with, are having less chances
of being applied in practice. The answer of the RQ
explores the frequency of the use of SE practices. The
answer to this research question is complementary to
, in the sense that it unveils if a specific practice
is applicable to the pilot cases, and in scientific soft-
ware development in general. Finally, the RQ
to explore the link between SE practices and the
causes of TD. More specifically, we explore if the use
of SE practice could prevent the causes of TD, and
consequently if their application can prevent the ac-
cumulation of TD in software systems.
3.2 Participants Selection
To answer the aforementioned questions, we per-
formed a questionnaire-based study in cooperation
with the following organizations, related to the devel-
opment of scientific software—see Table 2.
Table 2: Participants Selection.
Examples of Scientific Software
Lattice Quantum Chromodynamics (LQCD)
refers to a class of applications which con-
cerns itself with simulation of the theory of
strong interactions
KKRnano is a massively parallel code per-
forming Density Functional Theory (DFT)
Capture, which is used for inventing
new materials for CO2Capture and provid-
ing economically viable installation solu-
tions for industries
CNRS Metalwalls which is a supercapacitor simu-
lation from the energy storage application
INRIA INRIA is a research organization that fo-
cuses on scientific software development, by
providing tools that enable task scheduling
h, e.
., StarPU
LIU LIU is a university that focuses on research
activities concerning the development of
high-level software abstractions and compo-
sition frameworks for scientific software.
The most notable product of LIU is SkePU,
which is well-established in the scientific
software development domain.
For each organization, we asked our contact point to
forward the email to at least 10 scientific software de-
velopers per organization. To comply with GDPR, we
informed the participants of the survey that: (a) the
results of the study will be made available to them in
an aggregate form in case they are interested; (b) will
only be published in an aggregated form; (c) each par-
ticipant should complete the questionnaire only if he
/ she provides his/her consent, and (d) their data will
be erased upon participants requests.
3.3 Data Collection and Analysis
The data collection method was an unsupervised
questionnaire-based, aiming to provide input to all
research questions. Despite the questionnaire-based
nature of this work, we cannot characterize this work
as a survey, since we have reached a limited popula-
tion. The questionnaire was organized into three
parts, one per RQ: the structure of the questionnaire
is presented in Figure 1 and is repeated for all SE
practices presented in Table 1. The questionnaire was
provided online, in the form of Google Forms
ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering
Is "SE practice" an understandable SE practice?
(Very Difficult to Understand Very Easy to Un-
derstand) – 5 scales
How often do you use "SE practice"?
(Very Scarcely Very Often) – 5 scales
Can "SE practice" prevent the accumulation of TD,
caused by...
short deadlines?
inappropriate planning?
lack of knowledge?
lack of a defined development process?
the lack of tests?
ineffective project management?
lack of qualified professionals?
lack of experience?
outdated or incomplete documentation?
lack of commitment?
poor design (e.g., lack of refactorings, etc.)?
Other Comments
ree text
Figure 1: Structure of Questionnaire.
The use of Google Forms provided us the opportunity
to easily setup the survey instrument, whereas all re-
sponses were managed automatically. The main ben-
efit of this strategy is that no errors during the record-
ing of the responses can be introduced. At the end of
the data collection process, the dataset consists of 75
columns (3 questions x 25 SE Practices) and 31 rows
(responses). To answer the research questions, we
performed a quantitative assessment based on the
questionnaire data. The dataset has been analyzed us-
ing descriptive statistics and graphs.
In this section, we present the results of this study
based on the research questions that have been de-
scribed in Section 3.1. We note that in this section we
only present the raw results of our investigation,
which are cumulatively discussed in Section 5.
Figure 2: Study Demographics.
Figure 2 depicts the experience of the participants,
which is measured in years. More specifically, we can
observe that approximately 50% of the participants
have more than 10 years experience as scientific
software developers.
Familiarity & Usage of SE Practices by Scientific
Software Developers (RQ
/ RQ
To investigate the knowledge of scientists and the us-
age frequency of SE practices, we asked them how
familiar they are with the top-25 SE practices, and
how often they use these practices. Since the ex-
tracted information is vast, to present it comprehen-
sively, we have preferred to discuss the extreme cases
only. More specifically, we present:
Favourable SE Practices with which developers
are highly familiar and use them in practice. In
this category we have classified: “Reuse of Soft-
ware Libraries”, “Application Programming In-
terfaces”, “Object-Oriented Programming”,
“Task-Based Programming”, “Continuous Inte-
gration”, “Collaborative Software Development,
and “Parallel / Distributed Programming”.
Less applicable SE Practices that developers
know, but they prefer not to use them. In this cat-
egory we have classified: “Testing”, “Refactor-
ing”, “Integrated Development Environment”,
and “Code Generation”
Less familiar SE Practices only few developers
are aware of. In this category we have classified:
“Model Driven Engineering”, “Aspect Oriented
Programming”, “Paired Programming”, and “Pro-
cess Improvement Methods”.
In Figures 3-6 we visualize the results for RQ
, in the form of grouped bar charts for two favor-
able, one less applicable, and one less familiar prac-
tice. The bar charts correspond to the frequency of
each Likert scale value, in terms of familiarity to the
practice (blue bars); and the usage frequency (orange
Figure 3: Reuse of Software Libraries.
Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development
Figure 4: Application Programming Interfaces.
Figure 5: Testing.
Figure 6: Model Driven Engineering.
To answer RQ
, we have visualized the collected data
through a bubble chart (see Figure 7). We note that
for answering RQ
, we focused on Favorable SE
practices and Less familiar SE practices. The bubble
chart can be read in two ways: horizontally or verti-
cally. The horizontal analysis highlights the SE prac-
tices that mitigate most of TD causes, whereas the
vertical analysis denotes the SE practices that can be
used for mitigating specific causes.
Figure 7: Mapping of SE Practices and Causes of TD accumulation.
ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering
Figure 7: Mapping of SE Practices and Causes of TD accumulation(Cont.).
Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development
Which Causes can each SE Practice Mitigate? As a
threshold to answer this question, we have set the 10
answers; i.e., that at least 10 practitioners agree that a
specific practice can mitigate some TD cause. Below
we list the SE practices that can mitigate at least 2
causes of TD. As the most prominent SE practices
(that resolve 2 causes of TD), we identify two: The
application of Reuse of Software Library” can miti-
gate in total 3 causes of TD: short deadlines”, “lack
of knowledge or “lack of experience”; suggesting
that reuse is highly relevant for teams with low pro-
gramming experience (which is the usual case for sci-
entific software developers). The application of
Testingpractice can also mitigate 3 causes of TD:
lack of tests”, outdated or incomplete documenta-
tion” or “poor design”.
The following SE practices can resolve two
causes of TD. In particular, the application of “Use of
Specific Programming Languagepractice can miti-
gate the TD caused by lack of knowledge”, lack of
qualified professionalsor “lack of experience”. The
application of Skeleton Programmingpractice can
mitigate the TD caused by lack of knowledge or
lack of experience”. The application of Process Im-
provement Methodologiespractice can mitigate the
TD caused by short deadlines or inappropriate
planning. The application of “Test-Driven Develop-
mentpractice can mitigate the TD caused by lack of
tests” or “lack of experience”. The application of
Paired Programming” practice can mitigate the TD
caused by lack of knowledge or “lack of experi-
ence”. Finally, the application of Design/Code Pat-
ternspractice can mitigate the TD caused by lack
of experience” or “poor design”.
Based on the above, we encourage scientific soft-
ware developers to apply Reuse of Software Li-
braries and Process Improvement Methodologies,
as well as to work in a Paired-Programming man-
ner. The application of these practices is expected
to mitigate in total 40% of TD causes.
Which Causes of TD Cannot be Mitigated with the
Identified SE practices? To answer this question, we
focus on the TD causes that are reported to be miti-
gated by only one or no SE practice. Inappropriate
Planning”, “Ineffective Project Management”, and
Lack of Qualified Professionals are mitigated by
only one of the investigated SE practices. Addition-
ally, “Lack of Defined Development Process” and
Lack of Commitment are not reported to be miti-
gated by any of the investigated SE practices.
Thus, more research and practical focus is required
in the project management-related causes of TD,
since their mitigation seems neglected, compared
to more technical causes.
Other Findings. According to Rios et al. (2020), the
most common causes of TD are “lack of experience
and lack of knowledge. The SE practices that re-
solve these causes of TD accumulation are: “Reuse of
Software Libraries”, Skeleton Programming”, and
Paired Programming”. Therefore, we need to high-
light the importance of these practices as well. An-
other interesting observation compared to the results
from RQ
and RQ
with RQ
is related to the SE prac-
tice “Parallel / Distributed Programming”. Although
the results suggest that the scientists are familiar with
this practice and use it very often, they use it for other
reasons and not for mitigating TD. More specifically,
one researcher wrote that “This practice is something
we have to use to make our program parallel, but it
does not help in SE”, whereas another researcher
wrote that “it makes everything else more difficult. It
only helps with getting better performance”.
While designing this study, we have identified several
threats to validity. First, regarding conclusion valid-
ity, all interpretations are tentative ones, since (by
definition) surveys cannot support causality, but only
report trends and general beliefs in the state-of-prac-
tice. Additionally, the sample of this study is a bit nar-
row compared to other questionnaire-based studies;
however, it could not be expanded to the complete
software engineers’ population, since we focus on
scientific software development. Nevertheless, we
note that the wide-spread of the sample to many or-
ganizations, that vary across EU countries guarantee
to some extent the generalizability of the results.
Furthermore, we acknowledge that repeating the
study with a different set of scientists might yield dif-
ferent results; however, the study design is com-
pletely replicable since all data collection instruments
and procedures are presented transparently in Section
3. Finally, a threat to construct validity stems from the
fact that we presented to the participants only ele-
ments retrieved from the literature or existing tools;
therefore, we might have missed other aspects (e.g.,
other SE practices or TD accumulation causes) that
they consider important, but were not listed in tenta-
tive answers, considering also the lack of open-ended
ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering
In this study, we focused on the scientific software
development domain, which is a sub-field of software
engineering, limited to the implementation of soft-
ware for research purposes. The goal of the study was
to identify which software engineering practices can
be used in scientific software development to prevent
the accumulation of technical debt. On the one hand,
the study of SE practices in this domain is important,
since usually scientific developers are not software
engineers; on the other hand, TD management is also
considered as highly relevant for the domain, since
maintenance of such applications is frequent, whereas
also possibly miss-execution (due to errors) is very
To achieve this goal, we have performed a ques-
tionnaire-based study with approximately 30 scien-
tific software developers, from 5 organizations spread
across Europe. The results of the study unveiled that
several SE practices, such as Reuse or Proper Testing,
can prevent the accumulation of TD. On the other
hand, other practices seem as either irrelevant to TD
prevention (e.g., Parallel Programming), or as non-
applicable to scientific software development (e.g.,
Refactorings). These findings can be quite useful in
practice, since the most fitting practices can: (a) be
promoted in the training plan of scientists; (b) be en-
couraged to be used in practice by technical manag-
ers. Finally, we believe that even the process of exe-
cuting such studies contributes towards the develop-
ment of an SE culture in scientific software develop-
ment, pushing the community to move towards more
systematic engineering processes.
This work has received funding from two European
Union’s H2020 research and innovation programmes,
under grant agreements: 871177 (SmartCLIDE) and
801015 (EXA2PRO). The work of Dr. Arvanitou was
financially supported by the action “Strengthening
Human Resources Research Potential via Doctorate
Research” of the Operational Program “Human Re-
sources Development Program, Education and Life-
long Learning, 2014-2020”, implemented from State
Scholarship Foundation (IKY) and co-financed by the
European Social Fund and the Greek public (National
Strategic Reference Framework (NSRF) 2014–2020).
The work of Mr. Nikolaidis is funded by the Univer-
sity of Macedonia Research Committee as part of the
“Principal Research 2020” funding program.
Arvanitou, E. M., Ampatzoglou, A., Chatzigeorgiou, A. and
Carver, J. C. (2021). Software engineering practices for
scientific software development: A systematic mapping
study, Journal of Systems and Software. 172.
Avgeriou, P., Kruchten, P., Ozkaya, I. and Seaman, C.
(2016). Managing Technical Debt. in Software Engi-
neering (Dagstuhl Seminar 16162). Dagstuhl Reports.
6 (4). pp. 110–138.
Basili, V. R. (1992). Software modeling and measurement:
the Goal/Question/Metric paradigm.
Birdsall, C. K. and Langdon, A. B. (1991). Plasma Physics
via Computer Simulation. the Adam Hilger Series on
Plasma Physics. Adam Hilger, New York.
Cunningham, W. (1992). The WyCash Portfolio Manage-
ment System. 7
International Conference on Object-
Oriented Programming, Systems, Languages, and Ap-
plications (OOPSLA ’92). Vancouver, British Colum-
bia, Canada, October 18-22.
Digkas, G., Chatzigeorgiou, A., Ampatzoglou, A. and
Avgeriou, P. (2022). Can Clean New Code Reduce
Technical Debt Density? Transactions on Software En-
gineering, IEEE Computer Society.
Eisenberg, J. (2012). A threshold-based approach to tech-
nical debt. ACM SIGSOFT Software Engineering
Notes. 37 (2). pp. 1 – 6.
Li, Z., Avgeriou, P. and Liang, P. (2015). A systematic
mapping study on technical debt and its management.
Journal of Systems and Software. Elsevier. 101, pp.
Martini, A. and Bosch, J. (2017). On the interest of archi-
tectural technical debt: Uncovering the contagious debt
phenomenon. Journal of Software: Evolution and Pro-
cess, 29(10).
Martini, A., Bosch, J. and Chaudron, M. (2014). Architec-
ture technical debt: Understanding causes and a qualita-
tive model. 40
EUROMICRO Conference on Software
Engineering and Advanced Applications. pp. 85-92.
Rios, N., Spínola, R. O., Mendonça, M. and Seaman, C.
(2020). The practitioners’ point of view on the concept
of technical debt and its causes and consequences: a de-
sign for a global family of industrial surveys and its first
results from Brazil. Empirical Software Engineering.
pp. 1-72.
Runeson P, Host M, Rainer A, Regnell B. Case study re-
search in software engineering: Guidelines and exam-
ples. Hoboken: Wiley; 2012.
Yli-Huumo, J., Maglyas, A. and Smolander, K. (2016).
How do software development teams manage technical
debt? –An empirical study. Journal of Systems and Soft-
ware. 120. pp. 195-218.
Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientific Software Development