# The Gap between the Admitted and the Measured Technical Debt: An Empirical Study
## 6 The Rationale  
Based on the presented research questions, our research method, and the presented and interpreted results from our empirical study, we present our findings below. Let us discuss the individual research questions. **RQ1--Is there a difference in detecting the technical debt amount between its manual identification and measuring it with specialised tools? **  
Steps (3), (4), and (5) in our methodology (see Figure 1) were taken in support of this research question. Products' technical debt was measured twice with the two leading platforms and admitted by the developers. The results are shown in Figure 2, and the aggregated technical debt values in the SQALE ratings are presented in Table 3. The absolute and relative mismatches between the technical debt amounts were calculated, presented (see Table 4), and interpreted. Our findings, which are described in detail in Section 5, show that _there is a significant difference in the assessed technical debt amount between its manual identification and automatic measurement_. The finding holds for both platforms, SonarQube and Vector Squore, that were used in the experiment. **RQ1--What is the difference between the admitted and the measured technical debt amount? **  
In addition to confirming the significant difference between manual technical debt identification and its automatic measurement, our research also reports on the difference from the absolute and relative technical debt perspective. As detailed in Table 4, the average difference between the measured technical and admitted debt is 3% in the case of SonarQube and 4% in the case of Vector Squore relative to project effort. The standard deviation was 3% in both cases. However, our 14 production software products demonstrate the gap between measured and admitted debt in the range from the same value to a _multiplier of 10 and more_ between technical debts. In addition, technical debt ratings (see Table 3) can be even two classes apart (among our cases, one can find measured \"\(A\)\", admitted \"\(C\)\", and vice versa). **RQ1--Is the amount of measured technical debt dependent on the tool that is used to measure it? **  
The collecting, processing, and interpreting of the data in this research was done carefully, separately for the two leading platforms that enable technical debt measurement based on state-of-the-art methodology SQALE. Initial data suggested significant deviations between the measurements, since the average factor between measurements was as high as 2.8, which equals 2% on average, compared to the development project effort. However, due to the deviant results and resulting higher standard deviation in the data, statistical tests could not prove or disprove the significance in the different measurements. This is why the answer to research question RQ1b is that _this research cannot answer it_. However, we would _urge users to be careful while comparing technical debt values gained from different tools_; this is, in addition to our experimental data, demonstrated clearly in Section 5.1. Based on the empirical data, we would suggest development and quality assurance teams to rely on the same measurement platform throughout the project. **RQ2--What are the causes for possible deviations in the identified technical debt amount? **  
In Section 5.1, we presented several cases and situations that led to the different amounts of the identified technical debt. In the paper, we presented them using three categories: (a) technical debt items that appear only in the self-admitted technical debt, (b) technical debt items that appear only in the measured technical debt, and (c) differences in the rules implemented in the measurement platforms.