# The Gap between the Admitted and the Measured Technical Debt: An Empirical Study  
[PERSON]  
1 Faculty of Electrical Engineering and Computer Science, University of Maribor, Koroska Cesta 46, 2000 Maribor, Slovenia; [EMAIL_ADDRESS] (T.H. ); [EMAIL_ADDRESS] (M.H. ); [EMAIL_ADDRESS] (T.B. )1 Faculty of Electrical Engineering and Computer Science, University of Maribor, Koroska Cesta 46, 2000 Maribor, Slovenia; [EMAIL_ADDRESS] (T.H. ); [EMAIL_ADDRESS] (M.H. ); [EMAIL_ADDRESS] (T.B. approaches or even a dedicated tool. Their purpose is to support the proper decisions in situations where development teams are in doubt whether it is sensible to introduce some more debt to a project. One of the essential activities is the constant monitoring of the technical debt quantity. While determining the technical debt amount, the development teams are faced with the two major approaches. One is known as \"self-admitting technical debt\", where the developers are required to report and assess the technical debt themselves. They must keep records, called technical debt items, for every shortcut, a quality-compromising trade-off, or something they know that should have been done but was omitted deliberately [2]. A technical debt item consists of several attributes, among them also assessed effort (expressed in man-hours, man-days, and similar) to mediate the technical debt item. Typically, developers admit their technical debt via source code comments, issue tracking systems, pull requests, and commit messages [3]. [PERSON] et al. [2] define the self-admitted technical debt (SATD) as a deliberate quick or temporary fix that was introduced into the source code intentionally by the developers. The intention is usually driven by a feature demanding short deadlines. Sometimes, developers do not label their SATD with comments in their source code. The reasons may be because the source code should be anomaly-free, but it can also be a consequence of company-accepted practices. As a common reason for not labelling SATD in the code, [PERSON] et al. [4] also state a lack of time. Reporting SATD has spread to several different sources dedicated to technical debt management [4]. In opposition, one could also use the second approach for determining the amount of technical debt: technical debt measurement. Several tools promise that the technical debt can be measured by employing a static code analysis, a code smell detection, and other rule-based approaches, to determine bad design decisions or bad source code. This approach is promising, especially, when (a) the team does not keep track of technical debt accumulation, when (b) the team is confronted with existing software, or when (c) the quality assurance team just want to have an additional insight via an automatic indicator on their software's internal quality. The landscape of specialised technical debt management and measuring tools is expanding. Teams can choose between several types of tools that offer functionalities from assessing current debt quantity via measuring quality attributes to manual debt management tools. However, our several years of experience with managing technical debt in production environments systematically suggests that the assessed technical debt amount might be significantly different when developers would admit it themselves compared to the automatically measured technical debt amount. We also experienced the impression several times that different tools report significantly different amounts of measured technical debt. Based on the presented context, our aim was to investigate if and why there is a gap between admitting and measuring technical debt. We are not, however, advocating the correctness of any method, whether it be admitting or measuring technical debt. Our aim is not to validate if technical debt measurement works well, nor to measure developers' performance in self-admitting technical debt. Our aim is to investigate the possible gap between the two without a prejudice regarding one approach being correct.