Evaluating the agreement among technical debt measurement tools: building an empirical benchmark of technical debt liabilities

Amanatidis, Theodoros; Mittas, Nikolaos; Moschou, Athanasia; Chatzigeorgiou, Alexander; Ampatzoglou, Apostolos; Angelis, Lefteris

doi:10.1007/s10664-020-09869-w

Cited by 32 publications

(8 citation statements)

References 64 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…For TD Principal quantification a vast majority of tools exist 8 (e.g., SonarQube, CAST, Squore, etc. ); however, recent studies suggested that their results are not in agreement 9,10 . In SDK4ED we have opted to use SonarQube, since: (a) according to Avgeriou et al 8 is the most commonly used tool in industry and academia; (b) one of the main criticisms that it receives is that it neglects design and architectural problems, but in this study, we focus on code TD; and (c) it is open‐source, avoiding the dependence of SDK4ED on closed‐source software, limiting its availability.…”

Section: Setting the Scenementioning

confidence: 83%

“…In the near future, we plan to include in the platform additional refactoring identification approaches. Furthermore, regarding monitoring, we have already incorporated forecasting capabilities 29 ; and for TD identification we have introduced a machine learning approach 30 that is able to identify the artifacts with high‐levels of TD, using the intersection of three well‐known tools (Sonar, CAST, and Squore) 10 …”

Section: Discussionmentioning

confidence: 99%

“…); however, recent studies suggested that their results are not in agreement. 9,10 In SDK4ED we have opted to use SonarQube, since: (a) according to Avgeriou et al 8 is the most commonly used tool in industry and academia; (b) one of the main criticisms that it receives is that it neglects design and architectural problems, but in this study, we focus on code TD; and (c) it is open-source, avoiding the dependence of SDK4ED on closed-source software, limiting its availability. SonarQube quantifies TD principal by identifying code smells (as the corresponding quality model requirements-SQALE method 11 ) and calculating their remediation time.…”

Section: System and Artifact Level Analysismentioning

confidence: 99%

See 2 more Smart Citations

SDK4ED: A platform for technical debt management

et al. 2022

Self Cite

View full text Add to dashboard Cite

Technical debt management is of paramount importance for the software industry, since maintenance is the costlier activity in the software development lifecycle. In this article, we present the SDK4ED platform that enables efficient technical debt management (i.e., measurement, evolution analysis, prevention, etc.) at the code level, and evaluate its capabilities in an industrial setting. The SDK4ED platform is the outcome of a 3-year project, including several software industries. Since, the research rigor of the approaches that reside in SDK4ED have already been validated, in this work we focus: (a) on the presentation of the platform per se; (b) the evaluation of its industrial relevance; (c) the usability of the platform; as well as (d) the financial implications of its usage.

show abstract

Section: Setting the Scenementioning

confidence: 83%

Section: Discussionmentioning

confidence: 99%

Section: System and Artifact Level Analysismentioning

confidence: 99%

See 1 more Smart Citation

SDK4ED: A platform for technical debt management

et al. 2022

Self Cite

View full text Add to dashboard Cite

show abstract

“…The idea behind this experiment is to identify potential TD instances, and document their existence, then addressing them and removing their corresponding comments. We used PMD and SpotBugs because they are known to be good indicators for technical debt in the source code [24,25]. Upon the completion of the experiment, we calculated the average recall, and we found the average recall is 0.90, which is considered acceptable.…”

Section: External Validationmentioning

confidence: 99%

SATDBailiff- Mining and Tracking Self-Admitted Technical Debt

AlOmar¹,

Christians²,

Busho³

et al. 2021

Preprint

View full text Add to dashboard Cite

Self-Admitted Technical Debt (SATD) is a metaphorical concept to describe the self-documented addition of technical debt to a software project in the form of source code comments. SATD can linger in projects and degrade source-code quality, but it can also be more visible than unintentionally added or undocumented technical debt. Understanding the implications of adding SATD to a software project is important because developers can benefit from a better understanding of the quality trade-offs they are making. However, empirical studies, analyzing the survivability and removal of SATD comments, are challenged by potential code changes or SATD comment updates that may interfere with properly tracking their appearance, existence, and removal. In this paper, we propose SATDBailiff, a tool that uses an existing state-of-the-art SATD detection tool, to identify SATD in method comments, then properly track their lifespan. SATDBailiff is given as input links to open source projects, and its output is a list of all identified SATDs, and for each detected SATD, SATDBailiff reports all its associated changes, including any updates to its text, all the way to reporting its removal. The goal of SATDBailiff is to aid researchers and practitioners in better tracking SATDs instances, and providing them with a reliable tool that can be easily extended. SATDBailiff was validated using a dataset of previously detected and manually validated SATD instances. SATDBailiff is publicly available as an open source, along with the manual analysis of SATD instances associated with its validation, on the project website 1 .

show abstract

“…In addition, we relied on SonarQube to identify technical debt through the history of the analyzed projects to conduct this study (and the following studies in this thesis). SonarQube is one of the most widely used tools for assessing the level of technical debt present in a software system (Digkas et al, 2020;Amanatidis et al, 2020). According to a recent overview of TD tools , SonarQube is the most popular tool based on its usage in the scientific literature and online media channels.…”

Section: Ch4<<empirical Cycle>>mentioning

confidence: 99%

Technical Debt Repayment in Practice

Tan¹

View full text Add to dashboard Cite

Technical Debt (TD) is a metaphor used to describe a trade-off between the shortterm benefits of "cutting corners" in software development and the long-term sustainability of a software system. Researchers have classified technical debt into several different types, such as design or code debt. The amount of technical debt tends to increase during the evolution of software systems. When the increasing technical debt results in extra maintenance and evolution effort, it needs to be (at least partially) managed.Technical debt repayment is the TD management activity which refers to the remediation of technical debt by reworking design and implementation constructs. Paying back all technical debt may be infeasible since there is typically a shortage of resources that can be allocated. Moreover, business stakeholders often prioritize resources (money and time) on developing new features and fixing defects, rather than performing TD refactoring activities. Therefore, developers need to improve resource allocation for TD repayment due to the limited resources and competing business interests. Thus, investigating the factors that influence TD repayment is crucial in finding optimal solutions that maximize value and satisfy resource constraints. The thesis reports on the investigation of how TD is paid back in practice and what factors influence this repayment, by considering both software repositories and the perspective of practitioners.In order to address the stated problem, we first looked into how TD repayment occurs in practice and its evolution over time. Specifically, we focused on the TD fixing rate across projects and across issue types, the repayment effort and the survival time of TD items. The results showed that most of the repayment effort goes into improving testing, adding documentation, reducing complexity, and removing duplication. We also extended a previous study on the same topic that used several Java projects and compared the results of TD remediation in Python and Java perspectief kan niet grondig onderzocht worden door naar een enkele gegevensbron te kijken (bijv. broncode of gesprekken van ontwikkelaars). Daarom hebben we gekeken naar twee gegevensbronnen (issue trackers en broncode) om de tijdlijn te onderzoeken van TD items die ontstaan in broncode, gerapporteerd en besproken worden in issue trackers en vervolgens terugbetaald worden in broncode. Daarvoor hebben we 219 TD-items uit vijf open-sourceprojecten handmatig geëxtraheerd en geïnspecteerd.De resultaten toonden aan dat de meeste TD-items die in issue trackers geïdentificeerd en als opgelost vermeld worden, ook terugbetaald worden in broncode, terwijl ongeveer een vijfde verder besproken wordt nadat ze geïdentificeerd zijn. De opgeloste TD items in issue trackers gerelateerd aan Design Debt hebben een significant hogere kans om terugbetaald te worden in broncode, terwijl Test Debt items minder kans hebben. Bovendien, hoewel het lang duurt om TD items te identificeren (ongeveer een jaar), hebben ze de neiging om binnen een paar dagen daar...

show abstract

Evaluating the agreement among technical debt measurement tools: building an empirical benchmark of technical debt liabilities

Cited by 32 publications

References 64 publications

SDK4ED: A platform for technical debt management

SDK4ED: A platform for technical debt management

SATDBailiff- Mining and Tracking Self-Admitted Technical Debt

Technical Debt Repayment in Practice

Contact Info

Product

Resources

About