True, but what I think s_kilk was getting at is that sometimes (especially in software) a bad developer will put a "fence" somewhere without a reason. And if that person already left the company, maybe you can never find out why.

That's why it's important to start with some testcases of required behavior, and then refactor only code that is supported by tests. Because sometimes the fence is there for a reason, but often it's not.

Even bad developers have reasons, you may not be able to divine those reasons but they may be legitimate. The would-be refactorer would do well to consider carefully what the reason might have been, even if a git-blame reveals a less-than-excellent contributor.

As an programmer I always try to capture these reasons in my commit messages, after a decade of doing this I’ve gotten a lot of thank you notes years after leaving a project, and I’ve even reminded myself details about my own thought process that I had otherwise would have long forgotten.

One thing I’ve learned by having long tenures is that context change over years is much more likely the reason for nonsensical code than developer stupidity.

> some testcases of required behavior, and then refactor only code that is supported by tests

The difficulty is making sure that you have all the requirements and aren't missing any, and once a system gets big enough, that gets really difficult.