3 ms·

I agree with the entire premise but I do think the cost argument is a bit overblown. Adding "unnecessary" feature flags isn't really that big of a deal imo, fea

I agree with the entire premise but I do think the cost argument is a bit overblown. Adding "unnecessary" feature flags isn't really that big of a deal imo, feature flags are cheap to add and maintain. Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved. I think the true cost is that feature flags can cause code bloat and readability issues, since engineers typically aren't great about cleaning up feature flags after things have been rolled out. I think that's an easily solvable problem that doesn't really necessitate a scarcity mindset of "just use less feature flags / only when necessary" though. LaunchDarkly makes it pretty easy to track feature flag usage and remind people to clean up old ones.

locknitpicker 2mo ago
> (...) feature flags are cheap to add and maintain. Not quite. When you add a feature flag, you now have a system that has N separate code flows that you need to verify before launch,and then have to modify and retest to remove the feature flag. A feature flag ends up doubling the workload to test and verify the feature. > Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved. This is perhaps the most relevant point that the blogger misses. Feature flags are runtime switches that can extend simultaneously to multiple systems and even clients. You can't pull features from clients with a release, where week-long release processss can barely get you a 60% uptake. Redeploying away features in the backend can easily take half an hour, specially if it's a system that does multi region rolling deployments. If you want instant switches, your best option is switches flipped at runtime. That's what a feature flag is.
thraxil 2mo ago
> Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved. I would argue that if flipping a feature flag isn't faster than doing a rollback, your feature flags are not functional. They should be essentially instantaneous and the first thing to reach for as soon as you've identified a problem. > Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved. This I totally agree with. Using feature flags well requires some discipline on the team's part to stay on top of them and remove them once they've served their purpose.

locknitpicker 2mo ago

> (...) feature flags are cheap to add and maintain. Not quite. When you add a feature flag, you now have a system that has N separate code flows that you need to verify before launch,and then have to modify and retest to remove the feature flag. A feature flag ends up doubling the workload to test and verify the feature. > Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved. This is perhaps the most relevant point that the blogger misses. Feature flags are runtime switches that can extend simultaneously to multiple systems and even clients. You can't pull features from clients with a release, where week-long release processss can barely get you a 60% uptake. Redeploying away features in the backend can easily take half an hour, specially if it's a system that does multi region rolling deployments. If you want instant switches, your best option is switches flipped at runtime. That's what a feature flag is.

thraxil 2mo ago

> Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved. I would argue that if flipping a feature flag isn't faster than doing a rollback, your feature flags are not functional. They should be essentially instantaneous and the first thing to reach for as soon as you've identified a problem. > Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved. This I totally agree with. Using feature flags well requires some discipline on the team's part to stay on top of them and remove them once they've served their purpose.