Live data from Hacker News

Analysis of longevity of code across many popular projects

erikbern.com

11–20 of 52 posts

Re: Analysis of longevity of code across many popular projects

#11
post #8

The simplest explanation is that the exponential model is not a good one (does not correspond to the underlying dynamics), and so the half time value is not an inherent (time-independent) property of the codebase, but depends on its age. It seems to me that in most projects, the code evolves quickly in the beginning and then stabilizes on a slower linear decay. This would explain the observed dependence of the fitted…

He addressed this partly in the article. Even when looking just at the early days of the more mature projects the code churned much less than projects less mature now.

Re: Analysis of longevity of code across many popular projects

#13

This is awesome. I ran it on pyramid for fun. http://imgur.com/a/KZ9KR

A catastrophe based model seems more appropriate. You see big refactoring taking place. Only in a big number sum those Poisson-like events turn into exponentials.

Re: Analysis of longevity of code across many popular projects

#15
It looks like the exponential model isn't a good fit at all -- in all cases it undershoots the decay at the start of the graph and overshoots at the tail end. So while it might "look close" there is some systematic that your model doesn't account for. In particular, I don't agree that all code in a codebase has a constant risk of being replaced -- most projects have different components that are developed at different rates. Some components are legacy code that is likely to never change, while other parts are under rapid development. In fact, I'd argue that's why the tail is so long -- legacy code is called "legacy" for a reason. And the tip of the graph dives down so quickly because code being rapidly developed has a higher chance of being replaced.

Re: Analysis of longevity of code across many popular projects

#16
post #10

Maybe Linux is not rewritten because it doesn't have tests

It is being rewritten all the time, but new code per arch or driver dwarfs common.

Still, without a high and good test coverage that makes sure that the drivers don't break when the core is changed, it's not worth to do refactoring just to make the code cleaner. Still, it's amazing how much extra functionality was possible to be added
Post reply on HN