I work in a lot of old systems and this is something I have to remind myself of constantly--the people that were working on these systems before me were not necessarily dumber than me. If they made these choices, they may have had good reasons for it that are not immediately clear to me, but if I change it may have far flung consequences that I am just not aware of.
If a change has far flung consequences that aren’t obvious, the code is of poor quality. If the reasons for the decisions are non-obvious, the code is of poor quality. I’ve been bitten y assuming that people thought things through the first time too many times. If it’s not in the code base or documentation, I’m assuming that it was done for expedience. Not because they were dumb, but just because that part of the code base wasn’t important when it was written.
Trying to understand everything passively prevent you from actually understanding things, trying to change something will teach you about underlying issues or it will show there no issues.
Zoom out a little. Code can work perfectly fine technically yet have far-flung consequences in terms of business cases, human workflows, etc, etc.
So it's not as easy as saying "there's always a good reason" or "there's never a good reason". Make a fair effort at uncovering the reason and then it's a judgment call with insufficient data.
Exactly. Code can pass 100% of tests--but the tests only cover what the test writer knows about. Code, especially old code, can encapsulate TONS of weird human and business specific behavior that you don't know about or doesn't seem sensible at a quick glance. Don't be so quick to dismiss old code--people rarely set out to build something thats shitty and code, especially code that seems completely asinine, is rarely just in there for the lulz.
Chesterton's Fence sounds like it was retooled by Jordan Peterson in his definition of truth (broadly: anything evolutionarily useful, Making Sense podcast w/ Sam Harris).
Peterson takes it to weird places, IMO, and Chesteron's Fence works better.
"Don't remove a fence until you know why it was put there."
It was a rhetorical device to support conservatism from the beginning. Chesterton was using it to defend Catholicism, but it works just as well for racial segregation, slavery, voting rights restrictions, any status quo.
For the counterpoint from the late great Joe Armstrong,
> Rewrite from scratch with zero external dependencies - always the fastest way (or at least the most fun way) - it increases understanding. [1]
I don't have a permanent viewpoint on this, I kind of bounce back and forth. I definitely think that whole rewrites are important for getting the module boundaries right, and I think it's important to have seen a problem from a bunch of different perspectives, ideally some of them really bad and borderline outrageous, before you commit to one solution. (“This problem is NP-complete, you just want to brute force it?!” -- yeah it turned out that in practice n was no greater than 9 and you could in fact easily hardcode an upper limit and try all possibilities to find the best one. But even if you don't get lucky, the fact that ridiculous ideas came to mind suggests that all the good ideas were on the table at least once.)
Right now I am more inclined to enjoy rewrites because I am working on a project which itself was a rewrite, and I would like to rewrite it back to something more like what it used to be, hah. If I do get my way you can bet I will turn coat, “we can't rewrite this now, don't you know how expensive rewriting is?!”
