# The Gap between the Admitted and the Measured Technical Debt: An Empirical Study
## 5 Mismatch Identification
### The Causes for the Mismatch
);
* Strict requirements for **commenting*
* the code;
* Usage of the **latest best practices*
* (e.g., in the case of project #3, half of the automatically identified technical debt items are related to an inappropriate text manipulation; in the case of the JS code, the tools have a strict rule that every component should be defined in a separate file etc. );
* Detailed requirements for the **unit tests*
* (e.g., in the case of project #1, more than 80% of the automatically measured technical debt is related to the missing unit tests);
* technical debt items (code that was not accepted by the developers to represent a technical debt item; in the case of project #2, the developers claim that half of the automatically reported debt items are false-positives);
* Strict rules on **code duplication*
* (developers, in some cases, do it deliberately and do not want to remove the duplication due to better readability, etc.). * Items unique to the SATD:
* **Conceptual violations*
* in the code, which are related to the domain of the information solution and/or to the selected architectural style (e.g., in the case of project #1, the developers decided to make a player selection on the client to accelerate the development, but they know it should really be done on the server);
* **Security vulnerabilities*
* in terms of not or badly secured parts; tools find this to be close-to-perfect code (e.g., in project #5, the user interface is well coded, including the re-captcha method, etc. ; however, it is completely unsecured and CORS is completely opened on the server side);
* Code that was **commented on deliberately*
* but was left in the code. In order to capture the results of the cause analysis, based on the projects' technical debt items, the graphical summary is presented in Figure 3. When we compare the technical debt items between the tools, we can spot several repeating cases as a reason for the deviations. Let us, as a showcase, focus on products #7 and #9, where the gap between Vector Squore and SonarQube is among the highest. Some examples of the technical debt items and their differences are as follows:  
* Product #9:
* SonarQube measurement: 18 h/22 TD items;
* Vector Squore measurement: 5.1 h/25 TD items;
* Only 9 TD items target the same assets by both tools;
* Example: SQLCarsDatabase.java--SonarQube: 28 min; Vector Squore 7:30 min; they both report missing a unit test, and SonarQube adds three code smells--naming convention violations;
* Example: Drive.java (a value object with two attributes, getters, setters)--SonarQube: 30 min for providing a unit test and removing duplicate code; Vector Squore: 10 min for improving changeability;
* Product #7:
* SonarQube measurement: 69 h/66 TD items;
* Vector Squore measurement: 25.9 h/79 TD items--75% are Testability-related;
* Only 24 TD items target the same assets by both tools;
* The most problematic file according to the SonarQube is RouteCard.js (React Component; 340 LOC, total cyclomatic complexity: 17)--measurement = 50 min (unit-tests + reliability);
* RouteCard.js is hardly mentioned by Vector Squore--a missing unit test would be measured as a 5 min mediation cost. Similar examples are common to all the projects that were measured: a relatively small subset of common violations and several tool-specific violations that add to the final technical debt amount. One could be surprised that this is possible, since both tools implement the SQALE method. **The rule set**, which is the third level in the SQALE model, and how it is implemented in both tools is the answer. For example, for product #9, the source code of which is in Java, is exposed to 620 rules in SonarQube and 1968 rules in Vector Squore. Product #7, the JavaScript-based React web application, is checked by 275 rules in SonarQube and 882 rules in Vector Squore. Both platforms can extend their rule-base. In the case of SonarQube, this can be done manually, while Vector Squore offers an out-of-the-box rule-providing system.