3 ms·

I can summarise this article in 1 sentence: Before destroying/removing/deleting something, make sure you spend sufficient time to understand why it was created

I can summarise this article in 1 sentence: Before destroying/removing/deleting something, make sure you spend sufficient time to understand why it was created in the first place and if you can't, then leave it intact. No need to spread 1 piece of butter on a whole bakery worth of bread

dredmorbius 5y ago
If I'm reading your revision correctly, you're suggesting leaving the feature in place if you cannot spend the time to understand its justification, rather than if you cannot find a justification. Your wording could be read either way. The first interpretation is generally more defensible, but still not an absolute. There may be circumstances in which time does not exist and other exigencies prevail. As an example, if you come across a fence in the course of, say, responding to / evacuating from a natural disaster, you might consider briefly if there's some specific danger that the fence guards against (say, a cliff or other hazard), but determine that the greater benefit is in removal for the purpose of effecting rescue or escape. First-responders don't agonise over why car doors were created when deploying Jaws of Life, earthquake responders don't survey plans of buildings to determine why walls exist before demolishing or removing them to access victims. In less pressing circumstances, such as making incremental updates or changes to some system, performing some inquiry into purpose, intent, or function is strongly advisable, and Chesterton's Law is a check against naive and uninformed alteration without such considerations.
- joshuamorton 5y ago
  And this distinction is very important. Organizational scar tissue can and does develop, where things are a certain way and no one for sure knows why, but there are {vibes, superstition, ego, whatever} that develop into maintaining them. It's really important to challenge these things, but they're tricky specifically because no one owns the decision (the person who chose left, or forgot, or who knows) so a naïve application of "don't change what you can't figure out the reason for" fails when there may be no clearly documented reason, beyond a shared hunch that it mattered at some point. Sure you should still investigate, but if after a decent investigation you can't figure out why, yes, change the thing. Sometimes you'll be wrong, but this is what we have error budgets for.
  - dredmorbius 5y ago
    Quite and very much this. Where the change is needed and previous rationale can't be determined, if possible: - Note that you've made the change. - That the previous rationale wasn't clear. - If possible, provide for backing out the change if it proves ill-advised. Often an initial approach can be to disable or bypass a specific mechanism. E.g., put a gate in a fence, a bridge over a gap, disable a feature, etc. Watch to see what does or doesn't fail. In software, specific time-triggered events may exercise infrequently-traversed paths --- end of week, month, year, etc. Naturally, these are hard to detect in advance. More convoluted are conditions triggered rarely (lunar cycle ~= 19 years, leap years, Unix epoch overflows, etc.). This is where documentation and QA engineering will save butts.

dredmorbius 5y ago

If I'm reading your revision correctly, you're suggesting leaving the feature in place if you cannot spend the time to understand its justification, rather than if you cannot find a justification. Your wording could be read either way. The first interpretation is generally more defensible, but still not an absolute. There may be circumstances in which time does not exist and other exigencies prevail. As an example, if you come across a fence in the course of, say, responding to / evacuating from a natural disaster, you might consider briefly if there's some specific danger that the fence guards against (say, a cliff or other hazard), but determine that the greater benefit is in removal for the purpose of effecting rescue or escape. First-responders don't agonise over why car doors were created when deploying Jaws of Life, earthquake responders don't survey plans of buildings to determine why walls exist before demolishing or removing them to access victims. In less pressing circumstances, such as making incremental updates or changes to some system, performing some inquiry into purpose, intent, or function is strongly advisable, and Chesterton's Law is a check against naive and uninformed alteration without such considerations.

joshuamorton 5y ago
And this distinction is very important. Organizational scar tissue can and does develop, where things are a certain way and no one for sure knows why, but there are {vibes, superstition, ego, whatever} that develop into maintaining them. It's really important to challenge these things, but they're tricky specifically because no one owns the decision (the person who chose left, or forgot, or who knows) so a naïve application of "don't change what you can't figure out the reason for" fails when there may be no clearly documented reason, beyond a shared hunch that it mattered at some point. Sure you should still investigate, but if after a decent investigation you can't figure out why, yes, change the thing. Sometimes you'll be wrong, but this is what we have error budgets for.
- dredmorbius 5y ago
  Quite and very much this. Where the change is needed and previous rationale can't be determined, if possible: - Note that you've made the change. - That the previous rationale wasn't clear. - If possible, provide for backing out the change if it proves ill-advised. Often an initial approach can be to disable or bypass a specific mechanism. E.g., put a gate in a fence, a bridge over a gap, disable a feature, etc. Watch to see what does or doesn't fail. In software, specific time-triggered events may exercise infrequently-traversed paths --- end of week, month, year, etc. Naturally, these are hard to detect in advance. More convoluted are conditions triggered rarely (lunar cycle ~= 19 years, leap years, Unix epoch overflows, etc.). This is where documentation and QA engineering will save butts.