I worked at an organization that had gone years without any updates: 10 year old dependencies that had never been updated, actively developed Python 2 code base in 2022, servers with 1000+ day uptimes and hadn't been updated since before the pandemic, on and on.
It made it difficult to get anything done because you had to wade through a dumpster fire to make the smallest change.
> the phenomenon where working software seems to deteriorate even when the code is untouched
If the code is touched, and fails to keep up with dependencies, I might argue that's more a case of bit neglect. But maybe that's semantics.
I do agree that bitrot can be real though. Links rot off the web. If you're going to leave a project sitting on git without maintenance, you should probably capture the build context. Like shrink-wrapping a boat and storing it on land rather than just leaving it rusting away in the water for years.
It felt like “bit rot” to you because that’s how you defined “rot”, but it’s not how real rot works, which has nothing to do with changing.
It’s something that just breaks down without any changes in use case. If a wooden bridge rots away, nobody means that they were unable to add extra lanes. They mean it ceased to do what it previously did.
“Code calcification” is likely a better approximation of what you’re trying to convey.
“Bit rot” would be better fitting to actual storage loss, but this industry chose poorly.
It's supposed to be a joke, comparing the process of drift in the codebase with physical disintegration. Much like technical debt is not literally a balance owed to another party, or an object is not literally a physical lump of mass, and a class doesn't have a literal parent because it was never born.
I would call it developer rot. The code hasn't changed - and runs just as well (or badly) as the day it was written. It is the developers who somehow lose the ability (I don't know how - just read the code) to work with that code.
