The Impact of neglected Quality Assurance on Productivity

The productivity of a software development project can be raised by neglecting quality assurance and starting production with an inadequately tested application. One reason for this can be time pressure. An apparent positive effect: The new-development productivity is higher than in projects with more test efforts. 
 
But: Beyond the project duration the effects are:

• Higher defect rate compared with other systems
• Lower productivity when developing future releases or increments, due to the high effort for error analyses and corrections

In most cases these effects are not of lasting nature because the defect rate can be reduced to a "normal" level by high efforts required after production start. However this approach is short-sighted because the effort for tests, error analyses and corrections is simply being shifted from the new-development project to those who are responsible for the subsequent further development. And test effort is being shifted to the first users of a new system. 

The diagram below shows a sample course of defect density and productivity after production start (Rel. 1.0) which is typical in such cases. Contrary to the Impact of Technical Debt on Productivity these projects are mostly able to recover after a longer period, i.e. the defect density decreases due to the meanwhile found and fixed errors and the productivity increases due to the reduced efforts for error correction.

Course of Defect Density and Productivity in a case of neglected qa (example)

An indicator for neglected quality assurance is a low test coverage.

My post Measures for optimizing Productivity shows better measures for increasing the productivity.

Using Sonar for steady Analyses of the Code Quality

The platform Sonar allows static code analyses of different projects and presents the results in a standardised form. Sonar applies some own rules enhanced by the rules of integrated tools as e.g. FindBugs, Checkstyle or PMD (for the Java world).

The experiences with Sonar used in a huge portfolio of applications are good. For Java there are more than 800 rules available, which are well described, can be activated and deactivated and can be configured regarding the severity of violations (e.g. Blocker, Critical, etc.) or parameters. Experience has shown that it is better not to use the standard configuration but to discus an own configuration with the most experienced developers and to rate less rather than more rules as blockers. Further it is important that the process model respectively the quality gates clearly define that e.g. it is forbidden to use a release as long as there are blockers, which at least are potential production defects.

Sonar Dashboard showing the results of a Code Analysis (Sample)

Additionally to these rules Sonar measures the comment density, the rate of commented or duplicated code, the cyclomatic complexity, the lack of cohesion in methods (LCOM4) and the class complexity (response for a class, RFC), which are proven indicators for the code quality. Based on an own coding styleguide, which should clearly define threshold values for these metrics, a Sonar profile can be used to set these thresholds for an indication of warnings and errors for each metric. This makes sure that each application being analyzed will be measured and rated by the same standard.

Best practise is to integrate the Sonar code analysis in the build processes of the different applications. Then, after each new build, i.e. each night or continuously - according to the configuration, a new analysis result is available.

The Sonar web client presents the analysis results in dashboards and even in case of a huge portfolio of applications clearly structured. There are tools for e.g. the analysis of time courses or hotspots. The authorized user can drill-down for each violation into the code and, if required, declare it as false-positive.

The experience is that only with a tool such as Sonar the definition of a coding styleguide is really worthwhile, because the compliance can be checked without extensive time and in short intervals.

Information about Sonar can be found at http://www.sonarqube.org/features/.