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.
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.