Throughout my career, I've seen a lot of old code. Almost every company in Silicon Valley is started by writing some mediocre software and attempting to validate a business model without spending too much time or money on something that works well.
This is fine, and the amount of code that survives usually is relative to how "good" the code was originally - if you have the good fortune of working somewhere with no "founder code", either your founder was on the lower side of the ego spectrum, or their code was especially atrocious. Which is to say, if the product survived at all and you're not in the first cohort of employees, you have probably experienced a phenomenon called "Chesterton's Fence".
The origin of the quote is a passage in Gilbert Keith Chesterton's 1929 book "The Thing". In a chapter called "The Drift to Domesticity", he writes:
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.
This "fence" comes up a lot in software, especially old or poorly factored software - and often it gets translated to "if you can't or don't want to dig in to find the original purpose for something, it probably was put there for a good reason, so you should leave it alone". In large and/or high velocity codebases, this gets reduced to "don't delete things you didn't write".
Piles of fences
Lately, I've been feeling like while I understand the intention behind this quote and find it helpful, I also find it over-applied to the point of becoming a fallacy.
When taken without subtlety, you could extend it to mean:
A person, encountering a thing that actually has no use, will never be able to destroy that thing. In following this, we inevitably retain only the objects that truly have no purpose.
I've been calling the areas afflicted by this symptom "Chesterton's Junkyards" - piles of old, un-owned code, that nobody is empowered to change or refactor, and that arguably at least some of it literally has no purpose.
Cleaning up Junkyards
The point of this blog post isn't just to complain, but also to propose a reasonable solution: If you encounter one of these junkyards, consider only the contract, and ignore the junk.
If you cannot reduce the offending code to a contract (e.g. it has too many side-effects, or you lack the knowledge to safely distill and replace the contract), at minimum you should file a bug to the effect of "this area of code is a junkyard, and it needs to be cleaned up before it is changed" – effectively encircling the area with caution tape.
In most cases however, these types of haphazard and unplanned pieces of code are not load-bearing. When considering the contract of a given piece of code, you will likely find that the contract is simpler than the code, and possibly even unnecessary or redundant.
The key difference here is that while Chesterton suggests "seeing the use" of something, I'd propose that many things, especially in code, truly have no use; leading us to a true paradox. But if we instead "define the contract" of said fence – which is to say, we just observe its current functionality instead of attempting to understand its purpose – we can much more easily evaluate if it aligns with our design goals (which likely have changed since we erected the fence), and instead of having to dig in and understand something that may not make sense in the first place, just clean up the junkyard.