Some contradiction here:<p><i>Code doesn&#x27;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&#x27;s like entropy. You never &#x27;win&#x27; against entropy; you just try to last as long as you can.</i><p><i>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&#x27;s when the interventions stop happening, or don&#x27;t happen often enough, that code rot sets in.</i><p>In the first paragraph, the author says that code doesn&#x27;t decay if it&#x27;s left alone but does decay when it is changed. In the second paragraph, the author says the exact opposite.<p>A warning about the hazards of reasoning-by-analogy: you&#x27;ve got to be really clear in your head about how the analogy maps to the subject.