3 ms·
Uhm, it's interesting, I see a little contradiction in your two points...
by kuu 7y ago
Uhm, it's interesting, I see a little contradiction in your two points...
- dagw 7y agoThe person doing the screaming in option one would probably very much prefer you using option two. Option one assumes that you can easily reverse your action with no damage done, which very often isn't the case
- coldtea 7y agoWell, it's about balance. If you applied the "Scream" test for a component you don't know what it does in an airplane, it might fall/explode/whatever. If you do it in a non-critical codebase, it might just break the build, and have someone call you for it. In the first case, the Chesterton's fence caution is more advisable. In the second, you could go with a "remove it and see what happens" approach.
- jchanimal 7y agoThere were a few times in the development of Apache CouchDB where whole features were “accidentally“ removed as a way of pointing out that the test suite didn’t exercise them.
- yjftsjthsd-h 7y agoI would interpret them at saying, "if you don't know why something is there, break it", and "if you don't know why something is there, don't break it"; how are you interpreting them, then?
- yalooze 7y agoYes, that's deliberate. As others have said it depends on the context and the ease of reversibility / consequence if it's still in use. I see them as complementary. If the risk is low it may be simpler/quicker/more cost effective to turn it off and see if anyone screams. So long as you are listening for the scream and can easily turn it back on. Obviously this can be abused but there are times when it is useful. If the risk is high, definitely spend the time to understand why, even if it is non-obvious.