Developer analytics tools often contain a code quality metric called "churn", this is defined as "code which is deleted or rewritten shortly after being written" (e.g. in less than 3 weeks). This metric is then used to compute an "efficiency" metric which is assumed to be "the percentage of all contributed code which is productive work" for a given engineer.

Not only is there no evidence that such a metric will actually help your organisation, it appears to fly in the face of the evidence we have on the importance of lowering Cycle Time.

Companies with lower Cycle Time (time from development to code in production) are able to rapidly test ideas to gain quick customer feedback, resulting in product that is more likely to satisfy a customer. If you test something and your customers don't like it - you should be able to remove it without being punished for increasing some meaningless "churn" metric.

This encourages teams to be able to experiment faster with new ideas in the real world, thus increasing their ability to ship software that best satisfies market demand.

As an alternative to this metric, engineering leaders should instead consider using proven metrics like Cycle Time.