Please say that 'code rots' if you don't clean it. What does that mean?
Obviously code is text, not an organism that can change itself. So why does code 'rot' if you don't touch it? What makes it 'rot' and what does it actually mean?
Please explain, examples would be welcome.
The general idea itself is simple - code that has remained untouched for an extended period of time and now does not compile/run without some effort. The question of "how" is a little more complicated.
Given a piece of code and a fixed environment, the system's behavior will not change. This determinism appeals to our general sense of logic.
The issue is that our environments are never static. We are running newer compilers, different IDEs, servers have been upgraded and OS patches have been issued. Generally speaking, even the hardware has changed. Seldom do these differences seem big. We accumulate them, one by one and then realize that the new environment does not still work with the old code.
The crux of the matter is, of course, that this is a gradual process that we do not really take note of while the code was, in some sense, out of sight. This is what leads to the feeling that the code rotted. Like some leftovers, we left it unattended in the refrigerator and now the whole container is spoiled.
It may be fair to say "environment drift" is a more precise term for what happened in this situation than "code rot", but the latter more specifically captures how it feels to the system maintainers. Hence the popularity of the term.
In addition to Michael's answer which, while correct, is only part of the equation.
The other more common part is code that is continually updated, extended and modified. Since those processes are not 100% reliably perfect, code gets more and more bugs introduced to it over time. Worse, it tends to get more and more "correct but ugly/hacky" code. This reduces the integrity of the code, "rotting" it until it eventually falls apart.
