2 research outputs found
Long-Term Evaluation of Technical Debt in Open-Source Software
Existing software tools enable characterizing and measuring the amount of
technical debt at selective granularity levels. In this paper we aim to study
the evolution and characteristics of technical debt in open-source software. We
carry out a longitudinal study that covers the entire development history of
several complex applications. We study how technical debt is introduced in
software, as well as identify how developers handle its accumulation over the
long term. We carried out our evaluation using three complex, open-source Java
applications. All 110 released versions, covering more than 10 years of
development history for each application were analyzed using SonarQube. We
studied how the amount, composition and history of technical debt changed
during development, compared our results across the studied applications and
present our most important findings. For each application, we identified key
versions during which large amounts of technical debt were added, removed or
both. This had significantly more impact when compared to the lines of code or
class count increases that generally occurred during development. Within each
version, we found high correlation between file lines of code and technical
debt. We observed that the Pareto principle was satisfied for the studied
applications, as 20% of issue types generated around 80% of total technical
debt. Early application versions showed greater fluctuation in the amount of
existing technical debt. Application size appeared to be an unreliable
predictor for the quantity of technical debt. Most debt was introduced in
applications as part of milestone releases that expanded their feature set. We
also discovered that technical debt issues persist for a long time in source
code, and their removal did not appear to be prioritized according to type or
severity
The Changing Nature of Computational Science Software
How should software engineering be adapted for Computational Science (CS)? If
we understood that, then we could better support software sustainability,
verifiability, reproducibility, comprehension, and usability for CS community.
For example, improving the maintainability of the CS code could lead to: (a)
faster adaptation of scientific project simulations to new and efficient
hardware (multi-core and heterogeneous systems); (b) better support for larger
teams to co-ordinate (through integration with interdisciplinary teams); and
(c) an extended capability to model complex phenomena.
In order to better understand computational science, this paper uses
quantitative evidence (from 59 CS projects in Github) to check 13 published
beliefs about CS. These beliefs reflect on (a) the nature of scientific
challenges; (b) the implications of limitations of computer hardware; and (c)
the cultural environment of scientific software development. What we found was,
using this new data from Github, only a minority of those older beliefs can be
endorsed. More than half of the pre-existing beliefs are dubious, which leads
us to conclude that the nature of CS software development is changing.
Further, going forward, this has implications for (1) what kinds of tools we
would propose to better support computational science and (2) research
directions for both communities.Comment: 10 pages, submitted for FS