Figure - available via license: Creative Commons Attribution 4.0 International
Content may be subject to copyright.
Source publication
Technical Debt is a metaphor used to describe the situation in which long-term software artifact quality is traded for short-term goals in software projects. In recent years, the concept of self-admitted technical debt (SATD) was proposed, which focuses on debt that is intentionally introduced and described by developers. Although prior work has ma...
Context in source publication
Citations
... For example, Azuma et al. [2] investigates Satd in Dockerfiles. Xiao et al. [54] characterizes Satd-C in build systems. Lage et al. [13] studies usability TD. ...
Self-Admitted Technical Debt (Satd) is a particular case of Technical Debt (TD) in which developers rely on source code comments (Satd-C) or labeled issues (Satd-I) to report their sub-optimal technical solutions. In this paper, we first explore a sample of 286 Satd-I instances collected from five open source projects, including Microsoft Visual Studio Code and GitLab Community Edition. We show that in 45% of the studied issues TD was introduced to ship earlier (i.e., to deliver faster), and in almost 60% it refers to Design flaws. Besides, we report that most developers pay Satd-I to reduce its costs or interests (66%). To complement the previous exploratory results, we investigate the adoption of tools to support Satd-I documentation. For that, we build a large-scale dataset of 72K Satd-C and 20K Satd-I instances, extracted from 190 GitHub projects. We also implement a prototype tool, called AdmiTD, to automatically report Satd-C as GitHub issues. We use this dataset and tool to reveal that developers are not interested in the automatic transformation of Satd-C in Satd-I. Moreover, we show that it might not be feasible to create a tool to recommend explicit links between Satd-C and Satd-I instances.
... Using SATD comments to analyse developers' motivations has drawn attention from the research community [12]. This includes studying developers' reasons and purpose for introducing "Build TD" [19], determining intention through contextualised vocabulary [5], and finding priority of tasks to understand developers' logic [13]. ...
R is a package-based, multi-paradigm programming language for scientific software. It provides an easy way to install third-party code, datasets, tests, documentation and examples through CRAN (Comprehensive R Archive Network). Prior works indicated developers tend to code workarounds to bypass CRAN's automated checks (performed when submitting a package) instead of fixing the code-doing so reduces packages' quality. It may become a threat to those analyses written in R that rely on miss-checked code. This preliminary study card-sorted source code comments and analysed StackOverflow (SO) conversations discussing CRAN checks to understand developers' attitudes. We determined that about a quarter of SO posts aim to bypass a check with a workaround; the most affected are code-related problems, package dependencies, installation and feasibility. We analyse these checks and outline future steps to improve similar automated analyses. CCS CONCEPTS • General and reference → Empirical studies; • Software and its engineering → Software libraries and repositories; Software defect analysis.
