The formula involved for calculating defect density is simply (number of defects) / (lines of code). So if lines of code would be less it increases the chances of having a high defect density. In other words, if in a project design principles are strictly follwed and all duplicacy, all dead code, all redundancy is removed, it will only lead to lesser lines of code. Now this might be called an optimized piece of code. But that does not help with the defect density parameter.

If one is working on a project, where ultimately defect density is to be calculated, wouldn't it lead the programmers to ignore code duplicacy and dead code ?

Is Defect density a valid technique at all ?

  • What is the actual quality problem you're attempting to solve here? – Todd A. Jacobs Sep 8 '14 at 14:06
  • At times client sees the whole project's quality in terms of defect density. – Ankit Sep 9 '14 at 6:52

I'd avoid any metric that uses lines of code as part of it's calculation.

As you say, it creates an incentive for developers not to optimise code to make things look better. Even worse, you can just make the code far more verbose than it needs to be to 'improve' defect density.


You are right in that defect density - as well as any other statistical measure - can be abused, so it should never be used as a sole measure per se. However, when used judiciously, it may provide useful insights into the codebase. (That said, developers reasonably familiar with their codebase and the product can usually identify the most critical modules / components without the need of statistics.)

A few comments to your reasoning:

  • bug fixing should have priority over refactoring, so in a well working team, code being refactored should already be bug free as much as the team is aware
  • code duplication in itself is a source of bugs, e.g. when the same modification needs to be done in several different (duplicated) parts of the code, forget one place and you have a bug
  • when using any kind of statistical data in a software development team, it is crucially important not to tie any personal assessments, benefits or drawbacks to it, lest team members will find their way to skew the metric to their benefit (and to the project's detriment in the longer term)

In my organization (which uses CMMI-DEV V1.3 Staged), we use the concept of Defect Injection Rate (number of defects / hours of development), rather than the Defect Density Rate. This formula can be made granular for each individual feature/module/component and the technique gives a practical real picture on Cost of Quality, since the hours are billed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.