I’ve seen Chesterton’s quote used or misused in ways that assume that an extant fence must have some use that is both ① still existent, and ② beneficial; and that it can only be cleared away if that use is overbalanced by some greater purpose.
Right, this is indeed a misuse. The intended meaning is obviously that you ought to figure out the original reason for the fence and whether it is still valid before making changes. It’s a balance between reckless slash-and-burn and lost purposes. This is basic hygiene in, say, software development, where old undocumented code is everywhere.
This is basic hygiene in, say, software development, where old undocumented code is everywhere.
Yep. On the other hand, in well-tested software you can make a branch, delete a source file you think might be unused, and see if all the binaries still build and the tests still pass. If they do, you don’t need to know the original reason for that source file existing; you’ve shown that nothing in the current build depends on it.
This is a bit of a Chinese Room example, though — even though you don’t know that the deleted file no longer served any purpose, the tests know it.
even though you don’t know that the deleted file no longer served any purpose, the tests know it.
Yes, if you solve the Chesterton fence of figuring out why certain tests are in the suite to begin with. Certainly an easier task than with the actual code, but still a task. I recall removing failed (and poorly documented) unit and integration tests I myself put in a couple of years earlier without quite recalling why I thought it was a valid test case.
On the other hand, in well-tested software you can make a branch, delete a source file you think might be unused, and see if all the binaries still build and the tests still pass.
Unfortunately, this doesn’t work outside software. And even in software most of it isn’t well tested.
Unfortunately, this doesn’t work outside software.
Sure it does—that’s how a lot of biological research works. Take some rats, delete a gene, or introduce a nutritional deficiency, etc. and see how the rats turn out.
Right, this is indeed a misuse. The intended meaning is obviously that you ought to figure out the original reason for the fence and whether it is still valid before making changes. It’s a balance between reckless slash-and-burn and lost purposes. This is basic hygiene in, say, software development, where old undocumented code is everywhere.
Yep. On the other hand, in well-tested software you can make a branch, delete a source file you think might be unused, and see if all the binaries still build and the tests still pass. If they do, you don’t need to know the original reason for that source file existing; you’ve shown that nothing in the current build depends on it.
This is a bit of a Chinese Room example, though — even though you don’t know that the deleted file no longer served any purpose, the tests know it.
Yes, if you solve the Chesterton fence of figuring out why certain tests are in the suite to begin with. Certainly an easier task than with the actual code, but still a task. I recall removing failed (and poorly documented) unit and integration tests I myself put in a couple of years earlier without quite recalling why I thought it was a valid test case.
Unfortunately, this doesn’t work outside software. And even in software most of it isn’t well tested.
Sure it does—that’s how a lot of biological research works. Take some rats, delete a gene, or introduce a nutritional deficiency, etc. and see how the rats turn out.