5 ms·

Can you elaborate? It sounds like you've had some bad experiences, would love to hear them. (I've had mostly good experiences.)

by hashkb 10y ago

ilikerashers 10y ago
Sure. They create friction in a release process. Flags set via config files require constant updates to said files, not a problem in a small team. Work in a secure environment where config is controlled? You now need a process for controlling all these new flags. Have hard dependencies on config (this flag MUST exist)? You tie your application to your config, both now need to be released at the same time. Code clutter? Yes and it is avoidable. Also flags are not suitable to every type of feature so you're in a half way house anyway. Something which requires a DB change COULD be done via a flag but not worth the effort. My experiences are mostly around CD pipelines that start breaking because of complexity. Feature flags might suit some application deployments and that's great. In everything I've worked on, they can be replaced by incremental (non-breaking) updates. In that situation anyone can do the release, no deep-feature knowledge required.
- sciurus 10y ago
  It sounds like you are using a bad tool if feature flag creation or changes require editing a config file. We use Gargoyle at Eventbrite and there is a nice API and UI for making changes.
erichurkman 10y ago
I've seen a few feature flags turn into ways that a company/developer can gloss over fixing a really hard problem. A personal example: we were developing a new insurance billing workflow. Since it was a huge change, and very risky, and not all health insurance companies make it easy to test, we rolled it out practitioner by practitioner or customer by customer. We got to about 95% 'enable_improved_billing_flow=True'. The remaining 5% were turning into a huge project to migrate due to the specifics of their practice / their primary insurance companies / multitude of business reasons (those ~5% were an outsized percentage of our revenue). In the end, we ended up having to maintain two billing flows.
- sciurus 10y ago
  I'm curious: How do you think this rollout would have worked without the use of feature flags, and how would that have been better?

Can you elaborate? It sounds like you've had some bad experiences, would love to hear them. (I've had mostly good experiences.)

by hashkb 10y ago

Can you elaborate? It sounds like you've had some bad experiences, would love to hear them. (I've had mostly good experiences.)

ilikerashers 10y ago

Sure. They create friction in a release process. Flags set via config files require constant updates to said files, not a problem in a small team. Work in a secure environment where config is controlled? You now need a process for controlling all these new flags. Have hard dependencies on config (this flag MUST exist)? You tie your application to your config, both now need to be released at the same time. Code clutter? Yes and it is avoidable. Also flags are not suitable to every type of feature so you're in a half way house anyway. Something which requires a DB change COULD be done via a flag but not worth the effort. My experiences are mostly around CD pipelines that start breaking because of complexity. Feature flags might suit some application deployments and that's great. In everything I've worked on, they can be replaced by incremental (non-breaking) updates. In that situation anyone can do the release, no deep-feature knowledge required.

sciurus 10y ago
It sounds like you are using a bad tool if feature flag creation or changes require editing a config file. We use Gargoyle at Eventbrite and there is a nice API and UI for making changes.

erichurkman 10y ago

I've seen a few feature flags turn into ways that a company/developer can gloss over fixing a really hard problem. A personal example: we were developing a new insurance billing workflow. Since it was a huge change, and very risky, and not all health insurance companies make it easy to test, we rolled it out practitioner by practitioner or customer by customer. We got to about 95% 'enable_improved_billing_flow=True'. The remaining 5% were turning into a huge project to migrate due to the specifics of their practice / their primary insurance companies / multitude of business reasons (those ~5% were an outsized percentage of our revenue). In the end, we ended up having to maintain two billing flows.

sciurus 10y ago
I'm curious: How do you think this rollout would have worked without the use of feature flags, and how would that have been better?