Ask HN: Any name/metaphor for this particular kind of entropy / tech debt?
For example, maybe there is a frontend that connects to three separate backend servers, A, B, and C, which all handle some different, self-contained logical thing. Or maybe things are divided into key classes A, B and C, each of which encapsulates a self-contained piece of functionality. It's possible for A or B to fail without affecting C. If B crashes, you know it is due to a problem with some particular feature. It's all quite sensible and easy to reason about.
Then, later, after go-live... a new, unrelated major feature D is added. Instead of creating a new backend server or class to implement D, it is shoe-horned into the existing A/B/C backend server or classes or whatever. And then feature, E, feature F, etc... all shoehorned into whatever the original architecture / components were, instead of adding dedicated new components for D and E and F, just like happened for A/B/C.
Obviously, over time, this just leads to a big mess. Not only do you not end up with a dedicated, self-contained implementation for D, you also destroy the dedicated, self-contained components you originally had for A/B/C in the process, and after a bit of time it turns into a big unstructured mess.
I always find this kind of bizarre, because often the original structure is pretty sensible, and all that's required is to continue applying the same reasoning and techniques to new features as was applied to the original ones.
Sometimes there are administrative disincentives that encourage this, like requiring some onerous approval for a "new" server / class / source file, but a lightweight process for a "change" to an existing thing... but for the most part it just seems to be odd that people can't apply more of what's already in front of them, instead of destroying it.