I’m not sure inside/outside is what’s mostly going on when you’re on the fence about whether making a minor name improvement is worth it. It seems to me more like the following things:
Changing things has costs as well as benefits; if you rename the variable there’s a (hopefully small) chance that you screw it up somehow and break things. Note that this needs to be considered even when you zoom out, even when you consider policies as well as individual decisions, and even when you take the outside view. (Would you rather work on a stable codebase or one where things keep being renamed as other people decide that some name is better? Would you rather concentrate on fixing bugs and adding features, or would you rather keep having meetings where everyone discusses ten variables they think have slightly the wrong names? Would you rather have bugs turn up every now and then because someone renamed a variable but forgot about one place where it’s used, or didn’t update a bit of documentation?)
Looking at a single decision rather than the policy it implies.
Hm. So if you look at a single decision like “it isn’t worth refactoring this”, and then you extrapolate out into the policy it implies (“it isn’t worth refactoring for the most part”), you’re still left with the question of what to do with your macro-level conclusion of “it isn’t worth refactoring for the most part”. Is it a good conclusion or a bad one? You could just use a reducto ad absurdum argument of “of course that’s a bad conclusion”, but I feel like looking at other things in your reference class is (a big part of) the way to go.
Changing things has costs as well as benefits
Yeah, great point. I agree that those are important things to consider.
I’m not sure inside/outside is what’s mostly going on when you’re on the fence about whether making a minor name improvement is worth it. It seems to me more like the following things:
Looking at a single decision rather than the policy it implies. (Cf. “How I lost 100 pounds using TDT”.)
Changing things has costs as well as benefits; if you rename the variable there’s a (hopefully small) chance that you screw it up somehow and break things. Note that this needs to be considered even when you zoom out, even when you consider policies as well as individual decisions, and even when you take the outside view. (Would you rather work on a stable codebase or one where things keep being renamed as other people decide that some name is better? Would you rather concentrate on fixing bugs and adding features, or would you rather keep having meetings where everyone discusses ten variables they think have slightly the wrong names? Would you rather have bugs turn up every now and then because someone renamed a variable but forgot about one place where it’s used, or didn’t update a bit of documentation?)
Hm. So if you look at a single decision like “it isn’t worth refactoring this”, and then you extrapolate out into the policy it implies (“it isn’t worth refactoring for the most part”), you’re still left with the question of what to do with your macro-level conclusion of “it isn’t worth refactoring for the most part”. Is it a good conclusion or a bad one? You could just use a reducto ad absurdum argument of “of course that’s a bad conclusion”, but I feel like looking at other things in your reference class is (a big part of) the way to go.
Yeah, great point. I agree that those are important things to consider.