Analysis of longevity of code across many popular projects
erikbern.com
erikbern.com
The decay isn't actually decay at all, but represents the complement of lines that define peripheral functionality. Lines defining peripheral functionality typically require modification (refactoring) as additional functionality is added. The asymptote which all the curves illustrate but the fit cannot capture represents the proportion of irreducible core functionality.
Simply adding a constant to the fit might fix all the problems.
[0] I'm only mentioning this footnote due to the article picking on Angular (fairly or unfairly), but the point I made that this is footnoting is relevant to them potentially.
It's all about context. What's the cost of "breaking things"? Does your not-yet-monetized social network startup go down for a couple of hours? Or does someone die?
Also, I have witnessed first-hand the slowdown in productivity that a "move fast and break things" approach has when what you are breaking is your team's ability to work quickly and confidently with the code base.
I wonder if there any research articles discussing the correlation between code-change and other metrics like product quality, change frequency of team members, estimation success, etc.
My question sparked for your request of a RESEARCH article and not a "normal" blog post.
I would like to know why you want a "research" article, that I assumed being an academic article, instead of a blog post.
This article comes up with a tool measuring the half-life of the code and demonstrates it on some project. What I was requested as an addition is the discussion of correlation of this metric with other metrics.
Being said that, a "paper" makes a difference compared to a "blog post" at some cases. Sometimes, in order to convince your directors and project managers about your change proposals to the programming processes, you need to support your idea with more serious work.
For example, in my previous company, I could use such an academic research in order to demand more time budget for "code-cleanup" periods where the team focuses just to re-writing the parts of legacy code, instead of bugfixes and new features.
I am surprised that this small request offended someone.
What left me wonder is the assumption that an academic paper is more serious than a blog post; I frequent the academic and that is just not true, especially in our field.
Then, of course, upper management may not share this point of view.
We are openly discussing the article, we are deciding what we do like and what we don't like about it and we are deciding if the article is worth our attention.
How it is different from an academic peer review process?
Sure the academic peer review processes are blind, but those are a double edge sword.
How many lines of code will it be in fifty years? Will we have to come up with new systems to manage the fact that individuals only really understand smaller and smaller pieces of it? Will it reach a mass where like a black hole it collapses from some uncomprehensible failure?
There have never been things like this that just grow in complexity forever.
But it's perceptually less work to accrete a few hundred new lines to the system than to engineer a 10x reduction that introduces an entirely new architecture layer, so nobody does, or only a few research-driven projects. Programmers are, after all, lazy and deadline-driven. And while proprietary software tends to accrete due to corporate dynamics creating an environment of continuous growth, open-source projects are often built on accretion as an assumed benefit.
My own software goal, having viewed this landscape, is to be stubborn enough for long enough to score some of the 10x wins and share those so that "more with less" becomes a little more viable. I do think that all codebases go obsolete eventually, but the overall ecosystem doesn't have to depend on them so long there's data and protocol compatibility.
The evolution of the species? Homo sapiens seem rather complex.
Perhaps what we'll see is that over time, large portions of what have been long list of pedantic instructions become decision models that get tweaked over time. Imagine when referring to the size of a software system using two numbers: MLOCs and MDPs (Matured Decision Points). Not unlike industrial revolution assembly lines compared to the automated factories of today — modern factory workers are some degrees removed from the step-by-step movements.
Or a new implementation (or OS) could come along, with compelling advances and no baggage. The old code doesn't so much collapse as become obsolete.
https://blog.yoavfarhi.com/2016/12/06/half-life-wordpress-co...
Would this give newbies a great new tool to answer their question of which framework or language to learn?
Rails or Django? Django lasts longer. Angular or React? VueJs just a trend?
You could answer all these questions with this kind of analysis.
If someone wants to make a genuine contribution, a blog post contrasting the various decays of Javascript frameworks would be a hit.
But more on-topic, nice article, well done!
This might actually be an interesting metric in regards to project architecture and/or project management.
Totally agree that exponential model explanatory power is great.
Definitely some merit to reason #3 - people are more willing to work on something that they can easily build on top of.
Probably wouldn't be too hard for the interpreted languages.
There had been _many_ *nix'es by 2006, so the territory had significant prior art and with it collective deep understanding of the problems being solved. Angular sprouted alongside a number of other SPA frameworks in an ecosystem that was experiencing a "growth-spurt" (using that term loosely) — lots of variables.
Perhaps we could talk about "intrinsic churn" vs. "accidental churn". The former results from the codebase keeping up with the "drift" in the problem space; the latter comes from having to learn.
But it doesn't seem fair to directly compare 2005 14 year old stable 2.6 Linux to projects which did basically foundational initial releases and not mention it.
Thank you