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.

1 INTRODUCTION

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 “traditional” software

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-

282

Arvanitou, E., Nikolaidis, N., Ampatzoglou, A. and Chatzigeorgiou, A.

Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientiﬁc 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

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.

2 BACKGROUND CONCEPTS

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

http://www.td-survey.com/

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

purposes.

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

Library

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-

ment

roductivit

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-

crease

roductivit

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

artifacts.

Skeleton

Program-

ming

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-

cation.

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 Scientiﬁc Software Development

283

Table 1: Top-25 Software Practices (Cont.).

Practice Definition

Task

Scheduling

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.

Parallel

Program-

ming

A programming paradigm that enables the

simultaneous execution of multiple instruc-

tions to speed-up the solution of a computa-

tional

roblem.

Process

Improve-

ment

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,

etc.

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

roductivit

Develop-

ment Frame-

work

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

erational.

Require-

ments,

Design,

Architecture

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.

Quality

Assurance

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

reventive

ower is obvious.

Quality

Metric

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

suboptimal in terms of quality.

TDD A software development approach in which

test cases are developed before coding, so as

to s

ecif

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

software.

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.

Pair

Programing

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

TD.

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

atterns.

Advanced

IDE

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.

Code

Generation

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.

Collab.

Software

Developmen

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

mana

ement.

Specific

Programing

Language

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

ment.

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

284

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”;

http://www.exa2pro.eu

 Inappropriate Planning— Refers 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 Process— Refers

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 Management— Refers to in-

adequate management during the complete soft-

ware development lifecycle. Example: “Not fol-

lowing planning”

 Lack of Qualified Professionals— Occurs 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”.

3 CASE STUDY DESIGN

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 Scientiﬁc Software Development

285

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

aims

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.

https://forms.gle/KCemCmc8Gcnu54Us5

Table 2: Participants Selection.

Organiza-

tion

Examples of Scientific Software

JUELICH

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)

simulations.

CERTH

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

domain

INRIA INRIA is a research organization that fo-

cuses on scientific software development, by

providing tools that enable task scheduling

throu

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

286

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.

4 RESULTS

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

and

, 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

bar).

Figure 3: Reuse of Software Libraries.

Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientiﬁc Software Development

287

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

288

Figure 7: Mapping of SE Practices and Causes of TD accumulation(Cont.).

Practitioners’ Perspective on Practices for Preventing Technical Debt Accumulation in Scientiﬁc Software Development

289

5 DISCUSSION

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

“Testing” practice 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 Language” practice can miti-

gate the TD caused by “lack of knowledge”, “lack of

qualified professionals” or “lack of experience”. The

application of “Skeleton Programming” practice can

mitigate the TD caused by “lack of knowledge” or

“lack of experience”. The application of “Process Im-

provement Methodologies” practice can mitigate the

TD caused by “short deadlines” or “inappropriate

planning”. The application of “Test-Driven Develop-

ment” practice 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-

terns” practice 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”.

6 THREATS TO VALIDITY

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

questions.

ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering

290

7 CONCLUSIONS

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

costly.

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.

ACKNOWLEDGEMENTS

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.

REFERENCES

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.

193-220.

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 Scientiﬁc Software Development

291