I’m back for round two!

Anyone else have to use Feature Switches in their codebase, and if you do, what do you think?

A lot of feature switcheroo is implementation and architecture design.

If you skip that, yes. You'll end up in if shenanigans.

I'm not entirely a fan of feature switches __if__ they try to solve an "this shouldn't be accessible problem" which could be better solved by ACLs / permission.

If it's really to just disable certain code pathes, my question would be why...

If it's not a very compelling reason, I wouldn't do it.

In a nutshell, you're adding a lot of complexity to a project with feature switches - as you've to test every possible combination of features... :/

Which brings me back to implementation and architecture design: Feature switch as in a separate isolated feature or overlapping stuff? Overlapping is the one to avoid.

(E.g. disabling Export-Feature overlaps with the Print-Feature, as Print needs a Export of PDF)

@IntrusionCM I really wish it was to disable access but we use them whenever new code is wrote..

Yeah yeah I know, that’s technically okay, but the issue is we never get rid of them, so we have feature switches inside of feature switches, oh the pain.

Oh might as well mention feature switches for typos too

We use feature flags (sparingly) to update back-end API & front end client. The feature is deployed on backend, toggled off, client is updated, toggled on, then next update removed.

Whenever possible, we deploy feature branches using mocks instead to do demo's to business.

Other tricks are using a temp extra GET parameter or redirect requests to specific js/css/json assets with an browser ext like ModHeader (only temp for demo's)

Best use case for perm feature flags is probably for some yearly recurring change (e.g. christmas promition theme toggle)