plw (04/16/83)
Do computer programs suffer from entropy? That is, do they
deteriorate with time? Or is it the illusion of entropy from adding
new 'features' and correcting earlier bugs?
Hardware definitely suffers the 'ravages of time' and needs to
be repaired from time to time. There is nothing 'physical' about a
program to wear out, though. Sometime, however, any given program will
'fall apart' and not work as expected. A program designed to handle a
given task will, after a period of time, no longer be acceptable for that
task. Murphy's Law? Entropy? Task change?
Does anyone know the record for a program to run unchanged - 10
years, 5 years, 6 months, a week? It brings to mind the accusations hurled
at appliance and automobile manufacturers about planned obsolescence! Those
in the programming field seem to have no job security worries for a long
time to come (in the general sense, not necessarily the individual sense)!
Just a thought from a part-time armchair philosopher....
Pete Wilson
...we13!plwgsp (04/16/83)
In my travels through /usr/src/cmd, I have seen some pretty obscure algorithms, and some pretty messy code. The programs work, so they are there, but no one dares tries to change them. My favorite examples is cal.c, then comes find.c. I once made a minor change in a spelling correction program and the program did not work. I then found that the saved original source code would not compile into a working binary. The worst part was that I was defending in a week and some one on my thesis committee was on my back to fix the mess I had stepped in. Our local wizard looked at the code and said, "This function expects a parameter but is never sent one!" changed it, and the program worked again. My conclusion is: Only a perfect program or a really messy program never changes. The perfect ones are few (perhaps cal is perfect), and unfortunately, the messy ones are common (insert your favorite here). Gary Perlman BTL MH 5D-105 (201) 582-3624 [ucbvax!]mhb5b!gsp
rtris (04/18/83)
According to the Hacker's Dictionary, which came of the net about a year ago, this phenomenon is known as Software Rot. The entry reads approximately as follows: Software Rot, hypothetical disease attributed to software from the observation that any piece of code will cease to function after a sufficiently long period of time, "even though nothing has changed". Also known as Bit Decay. Ralph.
warren (04/19/83)
I have always heard "Program Entropy" referred to as "bit rot". It is a serious and ubiquotous phenomenon of computing systems. Any working program will in time tend to deteriorate if not periodically cared for. The minimal level of care requires periodic recompilation and fixing the bugs you discover. There are several sources of bit rot: 1) Compiler evolution (How many C programs still have things like "int foo 3;" in them?) 2) Operating system or other execution environment evolution. 3) Random bit errors in the source or object. (How many times have you really been able to recover a backup copy of something that you didn't touch in more than 2 years?) 4) Time bombs, like the infamous clock overflow bug that crashed a large number of OS/360 systems sometime in the 70's. The major complicating factor is that typically only one person understood how the original worked and has probably left by the time that bit rot occurs. Its not clear that she/he still understands it, even if available for repair. The only known technique for preventing bit rot is to hermetically seal the system, preventing the introduction of elements that promote rot. This is why bit rot is more severe in academic, research, and program development environments, where the latest version of everything is always used, than in comercial environments, where a system gets installed for a purpose and then just sits there doing that job. -- Warren Montgomery ihnss!warren IH x2494
mark (04/20/83)
Bit rot can occur even in a hermetically sealed environment. Two good examples are UUCP and netnews. These programs both worked fine when they were first put out. But then the volume of traffic grew and grew and pretty soon bits were flying all over the place. They have needed regular care and feeding to keep up with the traffic. For instance, various quadratic algorithms that didn't matter when there were 10 newsgroups and 5 articles/week matter a lot with current levels of traffic. -- Mark Horton
dave (04/21/83)
Well, some of our graphics software at U of Toronto hasn't been changed since 1976. (Then again, it's going by the wayside since the 11/45, which HAS aged, is being put to pasture.) Dave Sherman CSRG U of Toronto utcsrgv!dave
dmmartindale (04/23/83)
Uucp may suffer from bit rot, but it also suffers from having lots of holes in its code that don't have any guardrails around them. For example, try getting a transmission error that garbles your system name during the initial handshaking before the packet driver is operating. The uucico on the other end will happily talk to you, accept each file you offer, and then probably throw it away since the machine name it thought it got isn't in USERFILE. Worst of all, you pay for all the transmission time to send the stuff before it gets thrown away. Dave Martindale
pn (04/24/83)
Don't most USERFILEs allow everyone to do what anyone can do? If they do, then having the system name garbled during the initial handshake won't affect anything. Note that if there is noise and the packet driver is invoked, your transmission costs will probably be higher than normal because of all the retries, adding insult to injury when the files are thrown away. Still a novice at UUCP Phil Ngai