Software rots. Or at least ages. Software development methodologies may slow down this process, but eventually almost any software system becomes so hard to maintain that a reimplementation is inevitable.
But what is that thing that gets worse with time called? Integrity? Cohesion? Entropy? The amount of technical debt? Is there an agreed upon name for that property getting worse that causes that changes in maintainability?
Some large software are rotting quite slowly, because a significant part of them becomes redesigned/reimplemented/refactored from time to time.
Take for example the GCC compiler. It is 28 years old, has more than 13 millions lines of source code (and measuring its size is challenging; depending on the tools you are using you could get a size of 20MLOC), and is still alive. I don't know what parts of it are older than 10 years, but certainly some of them are (e.g. its garbage collector, or its pass manager, or the idea of Generic & Gimple representations, even if of course they all have evolved significantly and recently).
Likewise for the Linux kernel. It is 24 years old. And probably for Firefox.
And there is no moment where you could say that GCC or the Linux kernel has been entirely reimplemented.
My guess is that any large software (e.g. above ten million lines of code, even if we all know that is a poor metric) is never reimplemented. Either it gets replaced (by some new software with a different specification) or it is still continuously maintained, or it simply disappears because nobody cares... (perhaps that happened to strange operating systems on bizarre computers like Norsk Data 500 - which I have used during my studies at ENS Cachan around 1983)
I guess that IBM mainframe Operating Systems (from OS/360 to z/OS) is an example of that. On today's rare mainframes, it is possible that some legacy code in them is over 40 years. But of course, most servers are running Linux today, but you cannot say that Linux is a reimplementation of OS/360.
The reason for that is probably economical; I guess that it is hard to get the capital to rewrite such monsters from scratch. And also because rewriting such monsters would take years (and you don't have the guarantee that the result would be better). Read Brook's Mythical Man Month book.
Now, surely, over a large amount of time, every software would vanish. I believe that in 100 years, Linux or GCC (and even C or C++ or POSIX) could be forgotten.... But I'll be long dead before.
But I guess that technical debt is the word describing the best what you are thinking about.
I think it's about software fit to its environment and to developer's expectations.
What do I mean by environment: Software that doesn't evolve works with file formats and protocols that gradually come out of fashion. Operating system may be replaced making parts of the codebase seem odd at least even if they somehow still function. Old programs don't know Internet and misses lots of opportunities there.
What do I mean by expectations: Programming language of the software changes it's idioms slowly and ultimately comes out of fashion. Software methodology evolves and even that twenty years ago it was acceptable to write code without tests, it's suspicious at least now. So the perceived quality of twenty years old codebase is much lower in eyes of today's programmer as she cannot work with it in a way she expects.
I don't think there is a magical property that would make well-maintained program loose it's usefulness over time. The ultimate problem is that almost no one understands that "maintenance" doesn't mean just "fix obvious issues", but also "align the code with the changing world continuously". When you just fix obvious problems, you end up with software full of "oh, this is off" behaviours that no one wants to use or develop. And then you will say the code is rotten.
