3 ms·
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
by 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 agoQuite 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.