Technical Debt in the Peer-Review Documentation of R Packages: a rOpenSci Case Study

Codabux, Zadia; Vidoni, Melina; Fard, Fatemeh H.

doi:10.1109/msr52588.2021.00032

Cited by 12 publications

(17 citation statements)

References 50 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The collective interface between data collection and data analysis for a scientific field, including software, hardware, personnel, and shared practices Atkins et al (2003) Technical debt Short-term, sub-optimal choices in data and code that hamper future development without refactoring, such as missing documentation and bug-prone code (Hinsen, 2015;Codabux et al, 2021;Vidoni, 2021) Heterogeneous data Combinations of data collected at different temporal scales and/or with different properties, for example multivariate time series (e.g., acceleration) with intermittent geospatial locations (e.g., GPS) (Leinfelder et al, 2011;Michener and Jones, 2012) Literate programming…”

Section: Cyberinfrastructurementioning

confidence: 99%

“…Up to a point, technical debt is not a problem; rather, it is the natural side effect of important scientific tasks like exploratory analyses and prototyping tools. But eventually technical debt creates obstacles for future work (Codabux et al, 2021;Vidoni, 2021). Removing those obstacles requires either 1) resources allocated specifically to auditing and fixing data and code (i.e., refactoring Adorf et al ( 2019)) or 2) cyberinfrastructure that promotes best practices from the start.…”

Section: Cyberinfrastructurementioning

confidence: 99%

See 1 more Smart Citation

How Reproducibility Will Accelerate Discovery Through Collaboration in Physio-Logging

Czapanskiy

Beltran

2022

Front. Physiol.

View full text Add to dashboard Cite

What new questions could ecophysiologists answer if physio-logging research was fully reproducible? We argue that technical debt (computational hurdles resulting from prioritizing short-term goals over long-term sustainability) stemming from insufficient cyberinfrastructure (field-wide tools, standards, and norms for analyzing and sharing data) trapped physio-logging in a scientific silo. This debt stifles comparative biological analyses and impedes interdisciplinary research. Although physio-loggers (e.g., heart rate monitors and accelerometers) opened new avenues of research, the explosion of complex datasets exceeded ecophysiology’s informatics capacity. Like many other scientific fields facing a deluge of complex data, ecophysiologists now struggle to share their data and tools. Adapting to this new era requires a change in mindset, from “data as a noun” (e.g., traits, counts) to “data as a sentence”, where measurements (nouns) are associate with transformations (verbs), parameters (adverbs), and metadata (adjectives). Computational reproducibility provides a framework for capturing the entire sentence. Though usually framed in terms of scientific integrity, reproducibility offers immediate benefits by promoting collaboration between individuals, groups, and entire fields. Rather than a tax on our productivity that benefits some nebulous greater good, reproducibility can accelerate the pace of discovery by removing obstacles and inviting a greater diversity of perspectives to advance science and society. In this article, we 1) describe the computational challenges facing physio-logging scientists and connect them to the concepts of technical debt and cyberinfrastructure, 2) demonstrate how other scientific fields overcame similar challenges by embracing computational reproducibility, and 3) present a framework to promote computational reproducibility in physio-logging, and bio-logging more generally.

show abstract

Section: Cyberinfrastructurementioning

confidence: 99%

Section: Cyberinfrastructurementioning

confidence: 99%

How Reproducibility Will Accelerate Discovery Through Collaboration in Physio-Logging

Czapanskiy

Beltran

2022

Front. Physiol.

View full text Add to dashboard Cite

show abstract

“…Several authors investigated the differences across different types of TD [11,33,54,70,74,75], even demonstrating that scientific software may have either different frequencies and also exclusive types [19,52]. However, to narrow the scope of the project (and to limit the survey length to a 'participant-friendly' timespan), we selected three types only-Code, Documentation and Versioning Debt.…”

Section: Technical Debtmentioning

confidence: 99%

“…Nowadays, TD is regarded as an essential consideration when developing software [33,74], which can even sway developers' morale [11]. Moreover, it has also been expanded to cover scientific software [19,52]. Nonetheless, though there is a plethora of work related to improving processes related to project management in OR interventions (i.e., Soft OR) [1,27,50,86], to the authors' knowledge, approaching TD in MP remains a gap in the literature that has been previously highlighted [85].…”

Section: Introductionmentioning

confidence: 99%

“…This study aims to address this gap by providing a first exploratory study of TD in MP. We focused on three specific TD types: Code (the most commonly admitted by developers [7,22,75,89], and one of the most researched [33,54]), Documentation (the most impactful and interesting for scientific software reviewers [19]), and Versioning (given the relevance of versioning for open-science and handling TD [15,56]). To do this, we conducted an online, anonymous survey with well-established OR academics and practitioners, and gathered 168 full responses regarding self-reported practices that may favour (or control) TD.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

On technical debt in mathematical programming: An exploratory study

Vidoni

Cúnico

2022

Math. Prog. Comp.

Self Cite

View full text Add to dashboard Cite

The Technical Debt (TD) metaphor describes development shortcuts taken for expediency that cause the degradation of internal software quality. It has served the discourse between engineers and management regarding how to invest resources in maintenance and extend into scientific software (both the tools, the algorithms and the analysis conducted with it). Mathematical programming has been considered ‘special purpose programming’, meant to program and simulate particular problem types (e.g., symbolic mathematics through Matlab). Likewise, more traditional mathematical programming has been considered ‘modelling programming’ to program models by providing programming structures required for mathematical formulations (e.g., GAMS, AMPL, AIMMS). Because of this, other authors have argued the need to consider mathematical programming as closely related to software development. As a result, this paper presents a novel exploration of TD in mathematical programming by assessing self-reported practices through a survey, which gathered 168 complete responses. This study discovered potential debts manifested through smells and attitudinal causes towards them. Results uncovered a trend to refactor and polish the final mathematical model and use version control and detailed comments. Nonetheless, we uncovered traces of negative practices regarding Code Debt and Documentation Debt, alongside hints indicating that most TD is deliberately introduced (i.e., modellers are aware that their practices are not the best). We aim to discuss the idea that TD is also present in mathematical programming and that it may hamper the reproducibility and maintainability of the models created. The overall goal is to outline future areas of work that can lead to changing current modellers’ habits and assist in extending existing mathematical programming (both practice and research) to eventually manage TD in mathematical programming.

show abstract

Self-admitted technical debt in R: detection and causes

et al. 2022

View full text Add to dashboard Cite

Self-Admitted Technical Debt (SATD) is primarily studied in Object-Oriented (OO) languages and traditionally commercial software. However, scientific software coded in dynamically-typed languages such as R differs in paradigm, and the source code comments’ semantics are different (i.e., more aligned with algorithms and statistics when compared to traditional software). Additionally, many Software Engineering topics are understudied in scientific software development, with SATD detection remaining a challenge for this domain. This gap adds complexity since prior works determined SATD in scientific software does not adjust to many of the keywords identified for OO SATD, possibly hindering its automated detection. Therefore, we investigated how classification models (traditional machine learning, deep neural networks, and deep neural Pre-Trained Language Models (PTMs)) automatically detect SATD in R packages. This study aims to study the capabilities of these models to classify different TD types in this domain and manually analyze the causes of each in a representative sample. Our results show that PTMs (i.e., RoBERTa) outperform other models and work well when the number of comments labelled as a particular SATD type has low occurrences. We also found that some SATD types are more challenging to detect. We manually identified sixteen causes, including eight new causes detected by our study. The most common cause was failure to remember, in agreement with previous studies. These findings will help the R package authors automatically identify SATD in their source code and improve their code quality. In the future, checklists for R developers can also be developed by scientific communities such as rOpenSci to guarantee a higher quality of packages before submission.

show abstract

Technical Debt in the Peer-Review Documentation of R Packages: a rOpenSci Case Study

Cited by 12 publications

References 50 publications

How Reproducibility Will Accelerate Discovery Through Collaboration in Physio-Logging

How Reproducibility Will Accelerate Discovery Through Collaboration in Physio-Logging

On technical debt in mathematical programming: An exploratory study

Self-admitted technical debt in R: detection and causes

Contact Info

Product

Resources

About