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.

The Impact of Technical Debt on Productivity

Some measures for raising the productivity are not very recommendable:

• Incomplete implementation of requirements
• Postponed corrections of known defects
• Disregard of commentation and technical design
• Insufficient or missing documentation
• Insufficient test coverage
• Build and deploy processes too complex and not automatable

A development project increasing the productivity by such measures takes on technical debt which must be paid back including interest after this project is completed - while the further development. Interest payments are:

• increasing effort for further development, which results in decreasing productivity,
• above-average effort for defect analyses and corrections.

The impact of technical debt may look similar to the diagram below. After completion of a development project and production start of an application (Rel. 1.0 in this example) the productivity measured for the further development (Releases 1.1, 1.2, etc.) is decreasing continuously (see: Measuring Productivity in Software Development), provided that the input considers the total expenses including these for defect analyses and corrections. 

Course of Defect Density and Productivity in case of technical Debt (Sample)

Steady code analyses are suitable to detect symptoms of technical debt almost early, already while the initial development project (see: Using Sonar for steady Analyses of the Code Quality). 

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

Is Software with Zero-Defect Quality possible?

The expression of a zero-defect quality has been coined by Philip B. Cosby in the early 1960s. TQM (Total Quality Management) as well as Six Sigma consider a zero-defect production as desirable objective.

In software development zero-defect quality would mean that – depending on the definition, what a defect is – all explicit (described in a requirements specification) and all implicit requirements (e.g. typical expectations of non-functional characteristics as robustness, usability, etc.) are fulfilled. Due to the size and the complexity of software, but often also as a debt of a fuzzy or incomplete requirements specification, it is not feasible with reasonable expenses to verify that software is free of defects.

However zero-defect quality should be understood as an ideal goal. The issue is the common understanding of quality by all persons involved in software development. Software defects must not be considered as ‘normal’, i.e. a defect rate greater than zero is not acceptable. This should not lead to punishing developers who are responsible for defects, but better to a general root cause analysis for each defect to find out by which measures similar defects can be avoided in the future. This is the key for a continuous improvement of all areas related to software development, which definitely helps to approach to a zero-defect quality – even if it is not possible to reach it.