How can I estimate the lifespan of a line of code?

Question

I'm trying to figure out a way to analyze code longevity in open source projects: that is, how long a specific line of code is active and in use.

My current thinking is that a line of code's lifespan begins when it is first committed, and ends when one of the following occurs:

• It's edited or deleted,
• Excluded from builds,
• No code within its build is maintained for some period of time (say, a year).

NOTE: As clarification on why an "edit" is being counted as "death", edited lines would be counted as a "new" generation, or line of code. Also, unless there's an easy way to do this, there would be no accounting for the longevity of a lineage, or descent from an ancestor.

What else would determine a line of code's lifespan?

Answer 1

Andy Ozment looked at OpenBSD in 2006 with the same sort of question: Milk or Wine: Does Software Security Improve with Age?

You may be able to learn from his definition. It's also a very interesting paper, with an interesting conclusion as well, one that hasn't been incorporated into software management lore:

Over a period of 7.5 years and fifteen releases, 62% of the 140 vulnerabilities reported in OpenBSD were foundational: present in the code at the beginning of the study.

It took more than two and a half years for the first half of these foundational vulnerabilities to be reported. We found that 61% of the source code in the final version studied is foundational: it remains unaltered from the initial version released 7.5 years earlier. The rate of reporting of foundational vulnerabilities in OpenBSD is thus likely to continue to greatly influence the overall rate of vulnerability reporting.

We also found statistically significant evidence that the rate of foundational vulnerability reports decreased during the study period. We utilized a reliability growth model to estimate that 67.6% of the vulnerabilities in the foundation version had been found. The model’s estimate of the expected number of foundational vulnerabilities reported per day decreased from 0.051 at the start of the study to 0.024.

Answer 2

I don't think there is an answer for that. It's highly project dependant. Some are more stable over the years, others are more volatile/refactored/evolving over the years.

Moreover, it's difficult to measure. Is an editted line really the end of it's lifespan? What about only a cosmetic change like reformatting the codebase with tabs or spaces? IMHO that doesn't count as renewed codebase, but it would according to your criteria.

That said, I think a good chunk of the LOCs live forever.

The reason is simple: it's way easier to add new code rather than to remove some. Especially when the system is complex and grown over the years. It then quickly comes to a point where it's "risky" to remove or change non-trivial code. It could introduce bugs, break compatibility, introduce a butterfly effect of changes... So I think, the bigger the codebase becomes, the older it is, the more the LOCs are going to stay.

Moreover, only good programmers tend to cleanup codebases and reduce the lines. All others tend to pile up the LOCs. And so far, the latter are winning by far. ;)

Answer 3

Deleting or excluding a line of code definitely is an indication of the end of its lifespan.

Regrading editing, I would ask this question: Does this statement produces a different outcome after the edit?

If the answer is yes, then I'd say the previous statement is no longer available, otherwise I'd still consider it as the continuation of the previous statement.

Example of changing the outcome:

if ( a && b )

to:

if ( a || b )

Example of continuing the lifespan:

foo.bar( baz );

to:

foo.prototype.bar.call( this, baz );