Bitrot

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.

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".”

The oil company folk are the kind who prefer tree-trembling to the deep and unchanging sea.

I, too, when cold and hugging uncertainty for warmth, prefer to cut down trees for fire than to spelunk for hard diamonds.

“…we aren’t yet good at thinking about the intended lifetime of a software system when we’re designing it.”

And sometimes the life expectancy is so short that any old (or new) design will do.

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.

[0] https://en.wikipedia.org/wiki/Software_rot [1] https://en.wikipedia.org/wiki/Data_degradation

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.

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.

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.

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.

In my experience, a sort of opposite of this sentence tends to be true.

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.

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.