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.
