What to Fix? Distinguishing between design and non-design rules in automated tools
This work addresses the need for software practitioners to better manage technical debt by clarifying rule relevance, though it is incremental in formalizing definitions for automatic detection.
The study tackled the problem of distinguishing design-related rules from non-design rules in automated software quality tools, finding that 55% of rules were not design-related, 19% were design-related, and 26% caused disagreements among labelers.
Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.