Code doesn't decay on its own, of course. Left completely untouched, it will survive as long as you care to archive it. Decay — often called code rot or software rot — only sets in when changes are made, either to the code itself or to any of its dependencies. So as a rule of thumb, we can say that most code is decaying during most of its existence. It's like entropy. You never 'win' against entropy; you just try to last as long as you can.
In a healthy piece of code, entropic decay is typically staved off by dozens of tiny interventions — bug fixes, test fixes, small refactors, migrating off a deprecated API, that sort of thing. These are the standard maintenance operations that all developers undertake on behalf of code that they care about. It's when the interventions stop happening, or don't happen often enough, that code rot sets in.
In the first paragraph, the author says that code doesn't decay if it's left alone but does decay when it is changed. In the second paragraph, the author says the exact opposite.
A warning about the hazards of reasoning-by-analogy: you've got to be really clear in your head about how the analogy maps to the subject.
I think you misunderstood what he is saying (or maybe he wasn't clear enough): in the first paragraph he says that code decays when it is "changed", meaning when the codebase is enlarged, grown, more functionality added. On the second, when he talks about interventions, he's not refering to the same kind of changes, but to "code maintainence", which is a distinct and different kind of effort, the one that prevents the decay. For instance, from his point of view, a unit test is not a change to the codebase, but an intervention. Therefore, the codebase organism enlarges and rots with more code added, and bug fixing, test, refactors, etc, are the efforts needed not to rot. (Conclusion: the analogy is not the culprit :)
Code doesn't decay on its own, of course. Left completely untouched, it will survive as long as you care to archive it. Decay — often called code rot or software rot — only sets in when changes are made, either to the code itself or to any of its dependencies. So as a rule of thumb, we can say that most code is decaying during most of its existence. It's like entropy. You never 'win' against entropy; you just try to last as long as you can.
In a healthy piece of code, entropic decay is typically staved off by dozens of tiny interventions — bug fixes, test fixes, small refactors, migrating off a deprecated API, that sort of thing. These are the standard maintenance operations that all developers undertake on behalf of code that they care about. It's when the interventions stop happening, or don't happen often enough, that code rot sets in.
In the first paragraph, the author says that code doesn't decay if it's left alone but does decay when it is changed. In the second paragraph, the author says the exact opposite.
A warning about the hazards of reasoning-by-analogy: you've got to be really clear in your head about how the analogy maps to the subject.