3 ms·
I never found a great way to incorporate feature flags into my workflow without inducing significant mental churn managing 12-step rollouts over a dozen indepen
by stopping 2mo ago
I never found a great way to incorporate feature flags into my workflow without inducing significant mental churn managing 12-step rollouts over a dozen independent active flags. The changes I tend to make are sweeping, non-trivial refactors of base libraries with hundreds or possibly thousands of callers. These sorts of changes are exceptionally hard to flag (especially API changes), and it's stupidly easy for another developer to fat-finger a merge conflict resolution and drop one of my flag gates.
To this day I've never found any good guidelines for flagging changes like this without resorting to widespread file duplication, abuse of OOP, or an ad-hoc versioning system. It comes as no surprise that nobody in my organization was willing to do this sort of work.
- ollysb 2mo agoWhat you're describing sounds like code hygiene and refactoring not features.
- stopping 2mo agoIn my old org the policy was to flag every change, not just new features and behaviors. I'd even argue that refactoring is often a higher risk than adding a new feature path, because the scope of a refactor can touch nearly every user journey. So I can understand why the policy applies to refactoring. I'm just lamenting that this doesn't seem to be well-trodden ground, and being a person who cares deeply about reducing system complexity makes this whole thing kind of a bummer.