<?xml version="1.0"?>
<metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:title>The gap between the admitted and the measured technical debt: an empirical study</dc:title><dc:creator>Pavlič,	Luka	(Avtor)
	</dc:creator><dc:creator>Hliš,	Tilen	(Avtor)
	</dc:creator><dc:creator>Heričko,	Marjan	(Avtor)
	</dc:creator><dc:creator>Beranič,	Tina	(Avtor)
	</dc:creator><dc:subject>technical debt identification</dc:subject><dc:subject>self-admitted technical debt</dc:subject><dc:subject>technical debt measurement</dc:subject><dc:subject>difference comparison</dc:subject><dc:description>: Technical debt is a well understood and used concept in IT development. The metaphor,
rooted in the financial world, captures the amount of work that development teams owe to a product.
Every time developers take a shortcut within development, the technical debt accumulates. Technical
debt identification can be accomplished via manual reporting on the technical debt items, which
is called self-admitted technical debt. Several specialised methods and tools have also emerged
that promise to measure the technical debt. Based on experience in the community, the impression
emerged that the measured technical debt is of a significantly different amount than the self-admitted
debt. In this context, we decided to perform empirical research on the possible gap between the two.
We investigated 14 production-grade software products while determining the amount of accumulated technical debt via (a) a self-admitting procedure and (b) measuring the debt. The outcomes
show clearly the significant difference in the technical debt reported by the two methods. We urge
development and quality-assurance teams not to rely on technical debt measurement alone. The tools
demonstrated their strength in identifying low-level code technical debt items that violate a set of
predefined rules. However, developers should have additional insight into violations, based on the
interconnected source code and its relation to the domain and higher-level design decisions.</dc:description><dc:publisher>MDPI AG</dc:publisher><dc:date>2022</dc:date><dc:date>2025-03-27 11:11:46</dc:date><dc:type>Članek v reviji</dc:type><dc:identifier>92292</dc:identifier><dc:identifier>UDK: 659.2</dc:identifier><dc:identifier>COBISS_ID: 117810435</dc:identifier><dc:identifier>DOI: 10.3390/app12157482</dc:identifier><dc:identifier>ISSN pri članku: 2076-3417</dc:identifier><dc:language>sl</dc:language><dc:rights>© 2022 by the authors</dc:rights></metadata>
