Testing Technical Debt (TTD) occurs due to shortcuts (non-optimal decisions) taken about testing; it is the test dimension of technical debt. R is a package-based programming ecosystem that provides an easy way to install third-party code, datasets, tests, documentation and examples. This structure makes it especially vulnerable to TTD because errors present in a package can transitively affect all packages and scripts that depend on it. Thus, TTD can effectively become a threat to the validity of all analysis written in R that rely on potentially faulty code. This two-part study provides the first analysis in this area. First, 177 systematically-selected, open-source R packages were mined and analysed to address quality of testing, testing goals, and identify potential TTD sources. Second, a survey addressed how R package developers perceive testing and face its challenges (response rate of 19.4%). Results show that testing in R packages is of low quality; the most common smells are inadequate and obscure unit testing, improper asserts, inexperienced testers and improper test design. Furthermore, skilled R developers still face challenges such as time constraints, emphasis on development rather than testing, poor tool documentation and a steep learning curve.

Self-Admitted Technical Debt (SATD) is a particular case of Technical Debt (TD) where developers explicitly acknowledge their sub-optimal implementation decisions. Although previous studies have demonstrated that SATD is common in software projects and negatively impacts their maintenance, they have mostly approached software systems coded in traditional object-oriented programming (OOP), such as Java, C++ or .NET. This paper studies SATD in R packages and reports the results of a three-part study. The first part mined more than 500 R packages available on GitHub and analysed more than 164k of comments to generate a dataset. The second part administered crowd-sourcing to analyse the quality of the extracted comments, while the third part conducted a survey to address developers’ perspectives regarding SATD comments. The main findings indicate that a large amount of outdated code is left commented, with SATD accounting for about 3% of comments. Code Debt was the most common type, but there were also traces of Algorithm Debt, and there is a considerable amount of comments dedicated to circumventing CRAN checks. Moreover, package authors seldom address the SATD they encounter and often add it as self-reminders.

Context: Technical Debt (TD) is a metaphor used to describe code that is not quite right. Although TD studies have gained momentum, TD has yet to be studied as thoroughly in non-object-oriented or scientific software such as R. R is a multi-paradigm programming language, whose popularity in data science and statistical applications has amplified in recent years. Due to R’s inherent ability to expand through user-contributed packages, several community-led organizations were created to organize and peer-review packages in a concerted effort to increase their quality. Nonetheless, it is well-known that most R users do not have a technical programming background, being from multiple disciplines.
Objective: The goal of this study is to investigate TD in the documentation of the peer-review of R packages led by rOpenSci.
Method: We collected over 5,000 comments from 157 packages that had been reviewed and approved to be published at rOpenSci. We manually analyzed a sample dataset of these comments posted by package authors, editors of rOpenSci, and reviewers during the review process to investigate the types of TD present in these reviews.
Results: The findings of our study include (i) a taxonomy of TD derived from our analysis of the peer-reviews (ii) documentation debt as being the most prevalent type of debt (iii) different user roles are concerned with different types of TD. For instance, reviewers tend to report some types of TD more than other roles, and the types of TD they report are different from those reported by the authors of a package.
Conclusion: TD analysis in scientific software or peer-review is almost non-existent. Our study is a pioneer, but within the context of R packages. However, our findings can serve as a starting point for replication studies, given our public datasets, to perform similar analyses in other scientific software or to investigate the rationale behind our findings.

This paper argues that current practice in the Operational Research (OR) discipline needs to tackle management problems from a broader point of view by including a new perspective. While Hard OR is posed as the means to a solution, and Soft OR covers the stakeholder/business perspective, this paper proposes OR Engineering to tackle the model/program perspective. This proposal is substantiated by an empirical study that explored OR history and the rise of “wicked problems” in contrast to Software Engineering (SE) history and the idea of “no silver bullet”. The main findings are five areas for future works, intertwined between Soft OR and OR Engineering: agility, documentation of versioning, technical debt, systems testing and architecture. Overall, although the goal may be ambitious, this paper aims to stimulate reflective thinking and promote a novel and different line of action and research among OR and SE practitioners present and future.

As project management has become a critical subject in modern-world organisations, Operational Research (OR) needs to incorporate mechanisms to deal with rapid, unplanned changes as well as confusing information and stakeholders with conflicting values. Agile methods are widely used and tested in Software Engineering (SE) to deal with problems of the characteristics above. Because of this, after establishing that both OR interventions, as well as SE developments, have common stages and information evolution, this proposal aims to pose the challenge of applying agility to manage OR projects. Guidelines to adapt Agile Methodologies to OR are proposed, and a case vignette is studied as an initial test. Finally, future lines of work are considered to define how the larger project in which this proposal is embedded will continue.