is the theory that after a period of not being used, portions of code begin to stop working.
Like automobiles, programs are meant to be run.
Bit rot does happen. Dynamic RAM requires periodic refreshing, and on some platforms the refreshing is either under the control of software or it is
software (simply stepping through memory as part of a periodic interrupt will work). I once worked on a system where if the software was idle for long periods of time, it had a subtle effect on refresh. This caused the program to stop working when opcodes or data became corrupted. -- JohnPassaniti
Magnetic media (such as hard drives) also suffers from bit rot as the magnetic domains weaken over time.
Those definitions of BitRot
are ok, but not all that scary - the scary kind is the BitRot
that affects source code - you grab the copy, compile it, and it doesn't work, even though the CM system shows no changes to the source files. -- PeteHardie
The CM system shows no changes, but behind your back the compiler and libraries that you depend on have been updated, and some previously unnoticed fringe behavior in your code now breaks. BitRot
s are good at revealing BitRot
in that latter sense. ...Or DocTests give a secondary assurance and stay connected to the code within the same file. --MarkJanssen
Quite a few times since adopting them, I've found that if I went for a few days without running my UnitTest
s (on occasions when I stopped work on that project and had to work on something else for a while - I'm already aware of the perils of not running the tests for whatever code you're actually working on) when I came back and fired them up again, something would invariably have gone rotten.
Of course in this context it's not really BitRot
- the tests just remind you that even the stuff you don't think of as relevant to your code's working as it should may have an impact, you write a new test to check for the problem condition explicitly, then fix whatever change caused the problem, and life goes on.
But seeing that bar red when you expected it to be green does
give you a nasty turn, and reminds you how scary life must have been back in the days when you really did think of it as BitRot
can also be found on systems running for some time. No matter if it is a Windows or Unix system, constantly updating, installing and uninstalling software slowly adds cruft to the system, which makes it in the end a candidate for reinstalling. And most of the time it is not even easy to get rid of those systems. - Bernd Eckenfels
Physical bit-rot can and does happen. For example, a faulty motherboard can damage RAM causing bits to fail; this might not necessarily be noticeable for a while, but in due course it can render a system unusable. Replacing the RAM will treat the symptoms, but inevitably this RAM will also become faulty. The only solution in this case is to replace the system board.
(More likely that the board was marginal in some respect, and new RAM was able to tolerate its eccentricities better than somewhat aged RAM. Outright damage caused by a faulty board would have far more severe effects.)