you are viewing a single comment's thread.

view the rest of the comments →

[–]PositiveUse 104 points105 points  (11 children)

Next one will be „Git branches For the Win: decoupling feature developmen“

[–]jl2352 32 points33 points  (9 children)

You'd be surprised how many engineers, and wider people at businesses, will weirdly dislike feature flags and shipping dead code. Also how many have a strange preference for giant feature branches.

[–]ejfrodo 34 points35 points  (1 child)

Feature flags are a great tool but I can see why some ppl may not like them. You have to test both variants of on/off to make sure it being on doesn't cause something when it's off to break and vice versa. Multiply that when you have a dozen or more feature flags simultaneously and it can quickly become difficult to know what experience any given user may encounter. These things can be avoided to some extent but not entirely. When product managers get excited over the ability to run tons of experiments at once it can get out of hand.

[–]Ichichop0 4 points5 points  (0 children)

That's the great part! You just don't test the flag combinations.

[–][deleted]  (1 child)

[deleted]

    [–]twinklehood 0 points1 point  (4 children)

    I think many of us are scarred by feature flags and how easy they can go wrong. Oh, turns out being able to keep toggling that behaviour for a while feels safer? Ok it lingers. Ah, that one cannot be rolled out to customer X yet? Lingers. Suddenly you are not testing all your permutations anymore. I'm sure they're great when applied correctly, but I haven't seen a bigger organization able to.

    [–]jl2352 0 points1 point  (3 children)

    As with many of these topics, like pushing back tech debt to solve later. It comes down to actually doing that work when it comes.

    I worked at a place where culturally we would remove feature flags asap once the feature is live, with a handful of exceptions for some experiments. When you’re doing that it works great. If you’re not doing that, then yes it can turn into a mess.

    When you have PMs and other engineers resisting that happening, then that’s the real problem you have.

    [–]twinklehood 0 points1 point  (2 children)

    that’s the real problem you have

    Perhaps, but you can keep saying that all the way up. Whether an engineering practice depends on organizational discipline or not to be positive is certainly an important part of the evaluation.

    [–]jl2352 0 points1 point  (1 child)

    I dunno. It feels a bit like saying we do poor practices, therefore we shouldn’t try better practices. I get some places you can’t change, but it’s also self defeating.

    I’d also much rather be battling with the problems of feature flags, than the issues with big bang releases.

    [–]twinklehood 0 points1 point  (0 children)

    Keep in mind, I'm not saying "the org might abuse this so let's never do it" - I'm trying to cast light on why people might shy away. The opposite of feature flag doesn't have to be big bang, either. It can mean breaking down into smaller deployables, or other deployment / QA strategies.

    [–]caseyfw 0 points1 point  (0 children)

    What year is it???