Software rot is generally thought of as degradation of software due to a changing environment. For example, a program written a decade ago may no longer work with new versions of the libraries it depends on because some of them have changed without retaining backwards compatibility. This kind of thinking encourages a culture where software becomes obsolete unless it is constantly maintained.

A better approach might be to talk about the reliability of the environment the software depends on. Would you build a house on a bog?

It is often necessary to build on "bogs" (i.e. "actively developed" platforms), but it might be a good idea to also be compatible with a bedrock platform whose specifications are static and solid.

Software rot is a big issue for cultures that constantly produce new programs (such as games or demos) that are not supposed to be constantly maintained after release. Programs written for classical platforms (such as DOS or ?NES) usually need no post-release maintentance at all, while those written for e.g. ?Linux will likely cease working in a decade or two. Sometimes, serious ?media archeology work (such as finding specific versions of old libraries) is needed to get a program to run again.