Data Retention
The problem is data (or in the case of the article, program code---but that really is a type of data) retention. It is a huge issue that almost no one pays attention to.
My introduction to this problem was when I worked at a university (which shall remain nameless) lab, and had to pull up some old code that someone had written eight or ten years before. I didn't even know what programming language it was written in, so `find . -type f -exec grep -H <something> {} \;` wasn't up to the task, since I didn't know what <something> was. After looking in all the logical places, I went to the head programmer. "Oh, it's in ___ directory" he said, rattling off a several directory level deep path. And it was.
Did he retire? No, but while riding his bicycle to work one day, he was hit by a bus (ok, a car...). Fortunately he wasn't killed, but he was in the hospital for awhile.
You had better believe that in my next job (another university lab) I loudly and frequently stood on the soap box telling everyone who would listen about the need to document where data and code lived, and to put that documentation in some permanent place. The problem wasn't retirees (I was eventually one of the first) or people getting hit by buses, but rather people leaving for other jobs, taking with them the knowledge of where stuff lived. And over the 17 or so years I worked there, we had no less than a dozen cases where we needed to resurrect program data or code. Once it was because the organization we wrote it for lost their copy(!), another time it was because of a threat to sue (the results of our evaluation had made their software look bad).
Now I'm retired, and while only in my dreams have I been called in, I have this suspicion that things have gone missing.