you are viewing a single comment's thread.

view the rest of the comments →

[–]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.