7 ms·
I immediately thought of 2 related points: The Scream Test: If you see something and you don't know what it does, remove it and see if anyone screams. Chester
by yalooze 7y ago
I immediately thought of 2 related points:
The Scream Test: If you see something and you don't know what it does, remove it and see if anyone screams.
Chesterton's Fence [0]: "reforms should not be made until the reasoning behind the existing state of affairs is understood" (Though the purpose of this fence is not obvious, there may be valid reasons for its presence.)
[0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
- kuu 7y agoUhm, 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.
- m_eiman 7y agoI always apply Chesterton’s fence before breaking rules and regulations: if I see what the rule intends to accomplish, I can make sure to accomplish the same thing in another manner (walk across the street even if there’s a red light if there are no cars around). If I don’t see the point of the rule, I’m hesitant to break it.
- Ididntdothis 7y agoI apply the scream test when refactoring. Comment out a feature and wait until someone complains. After half a year or a year start removing things. Works pretty well. This works better with internal systems. I wouldn't do it with external customers or at least only with a lot of thought.
- mannykannot 7y agoYou may end up unable to remove features that are now only used because they provide a workaround to the damage you did earlier.
- Ididntdothis 7y agoThis may still be a win if the removed feature was one that made future changes difficult. The code bade I spend a lot of time working on has some old/weird features that it seems exist only to be tested but nobody is using them. But when asking the users you rarely get told to go ahead with removal.
- davinic 7y agoThis is a false dichotomy. If you're unsure of usage you could just instrument your code to log method calls and use that analysis to inform what maybe should be removed, but only if you first understand why.
- Ididntdothis 7y agoThis is client software. I am not getting any logs.
- marcosdumay 7y agoOnce somebody screams, you can dig why and fix the underlying problem. I imagine that none of the people criticizing the idea worked for long on any large organization.
- ken 7y ago> The Scream Test: If you see something and you don't know what it does, remove it and see if anyone screams. Spoken like someone who works on pure software, with Undo! Out in the physical world, the screaming would be followed by a loud crash. You don't touch anything if you don't know what it does. That's how equipment is destroyed, and people die.
- munificent 7y agoRight. The scream test only works when the cost of a scream is less than the value provided by discovering what the removed thing does.