This message was deleted.

We use split.io at Doma, and at Netflix we built our own (called fast properties). There are two common use-cases I’ve seen: 1) global config values 2) feature toggles The feature toggle use case was renowned for causing outages at Netflix, due to a lack of documentation, cleanup (removing old toggles), and unintended dependencies. We tried a few ways to introduce safety into the change process, but it was non-trivial to do.

Uber released some tooling around this a while back https://github.com/uber/piranha

Thanks for the feedback. Those are the same use cases I had on my list. Working on a product that enables this. Working on some example use cases so glad that lines up. Part of the service we are building is built in global multi-cloud deployment aka low-latency and strong consistency. From the looks of it, neither split.io or piranha supports strong consistency. Do you think that could be valuable in your use case, or do you not care about it?

I don’t think strong consistency was an issue for us, but it’s basically table stakes honestly

Yep, that makes sense. You essentially bypass all existing safety mechanisms that are in place.

Yes exactly! It's actually pretty crazy when you think about it. Here are the general problems I've observed with feature flags in general: 1. Bypassing of safe delivery practices 2. Lack of sufficient automated testing for stuff behind the feature flag 3. Deprecated / legacy feature flags with no documentation and original owner is now gone 4. Dependencies creeping into the code base expecting a feature flag to be in a certain state 5. Too many feature flags, becomes a nightmare to keep track of 6. Broad feature flags (large percent of code behind a flag)

It’s funny how it’s almost going full circle. We build to rigid release pipelines, then we introduce feature flags to bypass them and before you know it you need to create another rigid process to restrict feature flag use.

We build to rigid release pipelines, then we introduce feature flags to bypass them and before you know it you need to create another rigid process to restrict feature flag use.

Well said... this is exactly the issue!

BTW looking for beta testers if anyone is interested in testing our edge key-value store 🙂 We’d love some feedback.

We used feature flags at YikYak for both A/B testing and rolling out of new features. We made a rule to remove the flags once a feature was rolled out to 100% of the users. Having a small engineering team made this easy to coordinate. On my current team, we tried launch darkly and split but ended up creating our own, aptly named dark launchly ( 🙂 ) to do A/B testing.

@Michael Smith thanks for sharing. What made you decide to build your own?

At YikYak, we did it because there weren't any options at the time. On my current team, we mainly did it due to cost and we didn't really need all the bells and whistles split and launch provided. They are both great products, though.

Gotcha makes sense. What were your MVP requirements on your current team, if you don’t mind me asking.