I have no idea what it is you just said
Anecdotally, I've seen software being developed for the sole purpose of an event that would last a couple hours, software whose client needed it for the evening when calling in the morning, etc. It's a form of bitrot too: the code, event-specific, is as useful to us as the memories of said event a couple years in.
From the Wikipedia article he linked for software rot:
“[software rot] is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides.”
The software doesn’t physically rot. Its relationship to something (the world) does.
I attempted to draw a parallel of this to a database because, for many folks, the immediate environment of their app is a database of some kind. The world is kind of like a database, too, because it is read from and written to. But unlike an in-house data store, it changes without regard for dependant applications.
In the second paragraph I attempted to distinguish two kinds of programming endeavours. One is like chopping wood for fire, the other like retrieving and then cutting a hard substance. Whatever the purpose of the latter, it takes planning, experience, and the result is both intended to last a long time, and to be versatile. But the former is cheap and short and for the moment. You’ll have to do it again, many times, and in slightly different ways, depending on where you are, who you’re with, what the weather is like, and so on. Dijkstra’s seeming dismissal of rot may be directed against the latter, but not the former.
I guess my third commentary is that many, many software systems are not designed at the time of their construction, because they are sudden and their manifestation is opportunistic. This lack of design at the point of construction is an implicit assertion against the expected lifetime of any such system. It admits rot as a matter of course.