>it rots because api's, platforms and basically the tech that surrounds and it relies on changes.

The whole point of standards is for that not to happen

I don't agree with that statement. Standards are there to make development easier via an agreed upon "standard" way of doing things. Code rot has nothing to do with that. Things change all the time. No amount of standards stops change. Your code is rotting the second you're "done" with it, simply because everything else around it is still moving. Just accept that and learn to write code that is easily testable so that you can make your changes as necessary and have some confidence that you haven't broken anything in the process. Trying to write rot-free code is pointless. Trying to write code that is easy to update and repair is a worthwhile goal.

No. An FTP client written in 1987 works today because of standards. I meam standards that define how the application interacts with other applications and input.

That approach works for free command-line tools written for technology specialists.

But not if you are trying to make money with an app for the "general public", for example on the mobile app stores or oldschool shareware. Keeping it working is not enough, it must keep up with the latest trends in design and APIs that become available for extra features.

The old APIs and design guidelines could be a perfectly precise standard that still works - but it's the old standard when users expect new ones.

Code rot is a whole lot less inevitable if you choose to write your code in certain ways and pick the technology you use very carefully.

A lot of it has to do with not using the popular whiz-bang junk of the day.