I’d say that the phenomenon of old codebases having long half-lives is an example of survivorship bias - that is, codebases from 2001 that replaced half their code every 4 months have not survived long enough to be analyzed.
I’m trying to figure out how to do this analysis and actually derive a better conclusion. I largely don’t agree with the conclusion the article made, but I don’t really have any data for it.
If a piece of code lives for a long time, that this is not a 100% good thing. It could also mean that buggy code is sitting around forever. Forr my work projects I could probably categorize what was a “bug” commit vs. a “feature” commit. I’d want to see that feature commits had long lived code, and that bug commits that removed code were a bigger hit than commits that move / refactor code.
Having somebody dedicated to prototyping or sketching out functionality doesn’t strike me as inherently bad, for instance. (On the other hand, I’m not sure it’s inherently good, either.)
Organizational dynamics can have a lot to do with this also, particularly in dysfunctional organizations with personality conflicts, or places that have a single person responsible for e.g. making code style changes (whitespace, indentation, etc.)
I’d say that the phenomenon of old codebases having long half-lives is an example of survivorship bias - that is, codebases from 2001 that replaced half their code every 4 months have not survived long enough to be analyzed.
I’m trying to figure out how to do this analysis and actually derive a better conclusion. I largely don’t agree with the conclusion the article made, but I don’t really have any data for it.
If a piece of code lives for a long time, that this is not a 100% good thing. It could also mean that buggy code is sitting around forever. Forr my work projects I could probably categorize what was a “bug” commit vs. a “feature” commit. I’d want to see that feature commits had long lived code, and that bug commits that removed code were a bigger hit than commits that move / refactor code.
Another angle of investigation: code lifetime by author. Who writes the most code that eventually gets replaced by somebody else’s code?
And is that a bad thing?
Having somebody dedicated to prototyping or sketching out functionality doesn’t strike me as inherently bad, for instance. (On the other hand, I’m not sure it’s inherently good, either.)
Organizational dynamics can have a lot to do with this also, particularly in dysfunctional organizations with personality conflicts, or places that have a single person responsible for e.g. making code style changes (whitespace, indentation, etc.)