# On the Relationship between Self-Admitted Technical Debt Removals and Technical Debt Measures
## 4 Results
#### 4.1.4 Relationship between Change Type of Commit Removal and File not Found  
Considering the 4 types of changes that can be made to remove the SATD, which are listed in Section 1, the following Table 6 shows, for each project, the number of files not found, the changes that had been applied to these files, and the relative percentage. In Table 6, it is possible to observe that for Log4j, in 96.55% of cases (28 files) when the file was absent, this was determined by a Class Removal operation, where the class to be analyzed was deleted. However, for the remaining 3.45% of cases (1 file), the lack of the file was due to a Method Removal operation. For Gerrit, there is the same percentage of cases, 43.75% (14 files), where the file is not found, and the removal is due to the removal of a method or class. Unlike log4j, it has been found that there are some cases for which there is a change of method 9.38% (3 files), and the method is unchanged 3.12% (1 file). Hadoop represents the only case in which the absence of the files is due to the change method with a percentage of 43.66% (62 files). The removal of the class follows with 38.03% (54 files), followed by the removal of the method 11.27% (16 files) and the unchanged method 7.04% (10 files). Finally, Tomcat follows the same trend as Log4j and Gerrit, because the highest percentage, 96.60% (227 files) occurs in the case of class removal, which is followed by 2.56% (6 files) Method Changed and 0.42% (1 file) for both Method Removal and Method Unchanged. Figure 5 shows that in Log4j, Hadoop, and Tomcat, the most used type of modification to remove the TD, when the file is not found, is the removal of the class. Instead, in the case of Gerrit, in addition to the removal of the class, the method is removed as well. So, it means that in general, developers tend to completely remove the file or method with the TD inside. \begin{table}
\begin{tabular}{l c c c c} \hline \hline  & & \multicolumn{3}{c}{**Number of Files**} \\ \hline
**Change Type** & **Log4j** & **Gerrit** & **Hadoop** & **Tomcat** \\ \hline Class Removal & 28 & 14 & 54 & 227 \\ \hline Method Removal & 1 & 14 & 16 & 1 \\ \hline Method Changed & 0 & 3 & 62 & 6 \\ \hline Method Unchanged & 0 & 1 & 10 & 1 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Commits removals. Figure 4: Overview of the trend preservation percentage between negative delta commits removal and the next commit for each project. RQ2: To What Extent Do Self-Admitted Technical Debt Removals Lead to Lower Chidamber and Kemerer Metrics Values? To understand to what extent the metrics of Chidamber and Kemerer vary following the removal of the technical debt, the change in the value of the TD was evaluated concerning the CK metrics. Then, concerning a subset of metrics (lack of cohesion in method, depth of inheritance tree, public fields, and public methods), their fit with available thresholds was analyzed. We compared the TD value trend between two successive commits with the values of CK metrics. In particular, we verified whether a decrease in the TD corresponded to an improvement in most of the metrics listed above. On the other hand, we investigated even if a decrease in the TD value was associated with a worsening of most of the metrics. Specifically, if the developers' removal of the SATD did not produce improvements for the TD, we evaluated its effect on the other quality metrics. In particular, if a non-improvement of the technical debt (worsening or unchanged of the TD) found an improvement in most of the metrics, the action of the developers had a beneficial side effect for the system, despite a negative impact on the TD. If, on the contrary, the non-improvement of the TD is also associated with a worsening of most of the metrics considered, then a completely pejorative effect has occurred on the system.