3 ms·

Thanks for the response. This is the confusing part for me: I've been talking in terms of Feature toggles as described by Martin Fowler: http://martinfowler.com

by vinodkd 10y ago

Thanks for the response. This is the confusing part for me: I've been talking in terms of Feature toggles as described by Martin Fowler: http://martinfowler.com/articles/feature-toggles.html http://martinfowler.com/articles/feature-toggles.html, but it looks like LD is focusing on the AB testing piece primarily, with some parts of the base toggle functionality included by default. Can there be a feature switch that is configured not based on users, but on owner/admin's choice alone? More importantly, how do the LD SDKs help with the issues mentioned in the "Implementation Techniques" section of Fowler's essay - things like avoiding conditionals, DI, etc?

jkodumal 10y ago
Our goal is to build a developer-focused platform that gives teams the ability to adopt feature flags as a core part of their dev cycle-- including pretty much all of the use cases described in Fowler's article (ops, permissioning, etc.). Many of our customers are not using us for A/B testing at all. re: conditionals, DI: our SDKs focus on the base technique (flags based on conditionals), but it's possible to wrap that core with higher-level approaches like DI, etc. We're considering going down that path, but where it makes sense to do so, and not have to re-implement higher-level wrappers for every framework out there. So, e.g.-- in Ruby, I can see us providing higher-level APIs specific to Rails. Dependent feature flags are also an interesting problem-- we don't have a solution to that yet, but we do spend a lot of time thinking about feature flags, and I hope we'll have something on that front soon :)