Just a small clarification, this post is discussing software rot [0] and not data rot [1].
I think that most of us associate bit rot with the loss of data in a storage medium, frequently associated with corruptions in files causing them to not open or appear in a different form. There are file systems like ZFS and Btrfs that can detect and recover bitrot. This is something more obvious in photos where a few bit flips will result in a distorted/discolored/corrupted photo being displayed.<p>The concept of software rot due to old hardware, dependencies, updates, connectivity, architecture/application changes is something different and has to do with the design of software and (as correctly stated) not with the ageing or fatigue of the software.<p>[0] <a href="https://en.wikipedia.org/wiki/Software_rot" rel="nofollow">https://en.wikipedia.org/wiki/Software_rot</a>
[1] <a href="https://en.wikipedia.org/wiki/Data_degradation" rel="nofollow">https://en.wikipedia.org/wiki/Data_degradation</a>
You're telling me. I'm into vintage / retro PCs and use IA to find drivers, manuals, and so forth. There are some manufacturers who have gone out of business and aren't completely captured by IA. Some of the worst offenders obscured their downloads behind "CGI scripts" (indirect links requiring server-side code) rather than direct downloads. Organized, searchable, and comprehensive museum/archiving of digital artifacts in one place is necessary to avoid bitrot and linkrot. Schematics and bill of materials (BOMs) are necessary to repair, recreate, and/or simulate vintage hardware.<p>If I can't find hardware jumper information anywhere, some older cards are simple enough that knowing ISA or PCI bus pinouts, searching Octopart for datasheets, combined with a quality DMM can be used to painstakingly trace and determine functionality.<p>The other component necessary is the human brain-dump knowledge (wiki perhaps) of "what does what" to make sense of it.<p>The "let's delete everything old because old doesn't matter" mindset is how we lose past works forever. (If anyone can find "Mouse Commander", an independently-published TSR utility for Welltris to add mouse control, you'd be my BFF.)<p>PS: Interestingly, Matrox and the acquirer of Adaptec (Microchip) still have many drivers available. NVIDIA is also okay, but sometimes needs IA to get the last supported version of a particular driver.
> Legacy systems have legacy dependencies, and run in legacy environments.<p>In my experience, a sort of opposite of this sentence tends to be true.<p>Modern systems have too many dependencies, most of the time needlessly so, but still required. I recently used a Python package that required a specific version of the pandas behemoth to run, but it was only used to parse a date. Absolutely ridiculous.<p>On the other hand, the 40-year old Fortran code that everybody uses to compute special functions compiles and runs OK in a modern computer, and is completely standalone with 0 dependencies apart from the compiler.
<i>My first comment here a few years ago was on "A Codebase is an Organism" <a href="https://news.ycombinator.com/item?id=20787848" rel="nofollow">https://news.ycombinator.com/item?id=20787848</a> I repost it because I think catabolism of old concepts and systems is an important part of keeping older codebases alive.</i><p>Catabolism is another aspect of thinking about code as an organic entity that I find useful. Anabolic (growth) processes and catabolic (teardown) processes always accompany each other in biological systems. Too often we neglect to continually tear down and remove unused aspects of our systems.
Both anabolism and catabolism are always operating, though at different rates depending on the environment and needs of the organism. The funny thing is that catabolic processes will happily tear down important parts of the system, forcing them to be anabolically rebuilt. Things like bone and muscle mass. This seems wasted, but it has an extremely important purpose: uncontrolled anabolism is cancer.<p>I think the analogy to code is obvious. We've all seen codebases that have gotten out of hand (gotten cancer), and part of the reason they got that way is because the growth pressures had no countervailing teardown pressure. The market provides selective pressure in nasty ways: codebases and systems with cancer slow and die, and are replaced by younger codebases without uncontrolled growth.<p>How do we break that cycle? By encouraging catabolic activity culturally within our companies and codebases. Cleanup is incredibly valuable. Functionality that isn't being heavily used and is complicating implementation of new work should absolutely be on the chopping block. We don't have to be quite as aggressive as biological systems, but we shouldn't take their example lightly either.<p>This also provides insight into when cleanup doesn't matter: when the survival horizon of the organism is sufficiently short that cancer frankly doesn't matter. Startups shouldn't worry too much until they have product market fit. Once it's clear they'll be around for years more though, catabolic work will help ensure future health.
To be fair to them, they lived in a different world. The 60s, 70s, and 80s were a very safe time in computers. Virii and "hacking" ranged from curiosities to pests, but nothing particularly serious.<p>Today we've gone well past document-embedded-virus payloads and XSS and infected USB sticks to log4j, rowhammer, and spectre. And we've barely even scratched the surface. Just wait until JSON and XML exploits (i.e. exploiting differences in decoder behavior) become common!<p>Bitrot is only going to get worse, and we're going to need to design our systems and formats and protocols explicitly with change in their DNA so that they can evolve to meet new threats.
I think a source of bitrot the author doesn't mention comes from a combination of two things:<p>1. People modifying a large codebase generally don't have a complete understanding of the codebase (and this becomes more common the larger the codebase is).
2. "Chesterton's fence", i.e. modifying something you don't understand often has downstream effects you are unaware of.<p>It's the codebase equivalent of the 2nd law of thermodynamics - entropy always increases =).
Part of the cause of software rot is the fact that much of our code is tied to a specific platform or paradigm. So if you're working with Java 5 code it might be hard as hell to work with since it doesn't take advantage of the conveniences of modern Java. Same with legacy C++ apps or any other app to be honest that's older than a few years in most programming languages. Ideally, you can write around the core logic while replacing what's not actively supportable anymore but when you're stuck on a business mandated timeline you make due with what you can do to minimize the software rot.
I think the problem is not that software somehow would become worse as it ages. But that tons of software is and has been pretty crappy to start with, and to lesser degree has been worsened over time by modifications. At the same time our quality expectations for software have been dramatically increased over time, making the original poor quality even more apparent.<p>That viewpoint also partially explains Djikstras opinion; the software he made can be presumed to have been above average in quality so therefore it probably also aged better than most.
There doesn’t even need to be a changing world for software to require maintenance. Not only do people make mistakes and create bugs, but more importantly, nobody has perfect knowledge of the problem they’re trying to solve, so they will always build the slightly wrong thing.
Imagine your database is a sensor network instead of some schema-ful/typed data store. Field operators unbeholden to you keep adding, removing, or updating sensors. Your data format evolves underneath you, and you behave more like a magic carpet pilot than a builder of things unbreakable. You’re attempting to store the flight path as best as you can, update configurable sensors for the most profitable reads, but what you record is a direct reflection of the current sensors and their current settings.<p>I am wary of hastily agreeing that Dijkstra missed something. He may have been talking about specific, general purpose algorithms, which do not change much once conjured. There is another type of software, though, a software that sits atop the immutable spellcraft, a software that attempts to shake the boughs of profit trees at specific points and places in time and space.<p>Dijkstra says “Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".”<p>The oil company folk are the kind who prefer tree-trembling to the deep and unchanging sea.<p>I, too, when cold and hugging uncertainty for warmth, prefer to cut down trees for fire than to spelunk for hard diamonds.<p>“…we aren’t yet good at thinking about the intended lifetime of a software system when we’re designing it.”<p>And sometimes the life expectancy is so short that any old (or new) design will do.