
Show HN: Feature flag management for feature lifecycle control - eharbaugh
https://launchdarkly.com/
======
eharbaugh
Hi, I’m Edith Harbaugh, CEO & co-founder of LaunchDarkly. Feature
flagging/toggling is a best practice of continuous delivery. Feature flagging
is easy - you can do it with a config file or a database field. However, once
you start feature flagging at scale, your feature flag config files can become
a junk drawer & a form of technical debt.

LaunchDarkly is a feature flag management system that allows you to scale up.
You get an intuitive UI that non-technical users can control feature flags
with - for example, a Product Manager can turn on functionality. We also give
you access level controls and audit logging - allowing you to control who can
change which feature flag and get visibility on these changes. As well, we
offer SDKs for multiple languages so you can use feature flags consistently,
across mobile and web. When you’re ready to use feature flags at scale, we
hope you’ll use LaunchDarkly.

Would love your feedback about how you’re using feature flags already, and
what you’d expect to see from a feature flag management system.

~~~
vinodkd
So how exactly does launchdarkly help with feature flags becoming a junk
drawer/tech debt? I can see how the intuitive ui would help in general, but
what I was really expecting to see was:

* A way to manage dependent feature flags, because god knows once those non-technical(and technical) users have switches they can throw, they're going to ask for/build features that are dependent on each other in subtle ways

* A distinction between a true feature flag and what I call a "release" flag, ie, a feature that's not yet fully built, but that will not be optional once fully built and released, so its flag goes away at some point.

Also, btw, do you have an API for the flag creation itself, not its use, ie a
addFlag()/removeFlag() API?

~~~
jkodumal
We do have some features to help manage the lifecycle of feature flags. For
example, we can determine when a flag has been "flipped on" for everyone, and
notify you that it's time to remove it. We can also determine that a flag has
been removed from your codebase, and prompt you to remove it from LD
([http://blog.launchdarkly.com/launched-flag-status-
indicators...](http://blog.launchdarkly.com/launched-flag-status-
indicators/)).

We have more coming, including an ability to mark "permanent" flags that
should never be removed.

The product is built API-first-- everything in our UI is driven via our own
REST API. Docs are here:
[http://apidocs.launchdarkly.com/](http://apidocs.launchdarkly.com/)

~~~
vinodkd
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
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 :)

------
tldnr
Seems like a great product! Our inhouse flagging system is painful to use when
applying features en-masse, and makes "fast" rollbacks virtually impossible.
That, and other reasons, make this seem like a good alternative.

What's the flow like for a developer creating their own environment? I'm a
little concerned that asking developers to visit a third party site/be
connected to the internet to use feature flags locally be pretty inconvenient,
especially if the developer is working offline. Would you consider adding a
simple server implementation that could run locally and do feature flagging on
a per user basis (rather than rolling out to percentages, to prevent misuse)?

~~~
pkaeding
For local development, you can create an 'environment' for each dev, which
will maintain a separate set of targeting/rollout rules for each feature. This
will make development/testing fast when you _are_ connected to the Internet.
You can flip the toggle value on the LaunchDarkly dashboard, and it will be
instantly updated the next time your code gets the feature flag.

You can also provide a default value that will be used if the network is not
available. You can read from a config file to drive this if you need to, to
allow devs to specify the flag value when offline. This is what we do for our
dogfood environment (prod, staging, and dev environments all talk to dogfood,
but dogfood doesn't have another LaunchDarkly to talk to).

Hope that helps!

------
swsieber
Meta question: Does launch darkly use launch darkly for new features? Or is it
mostly stable or branching out into new areas (like the Android support)?

~~~
jkodumal
Of course-- we have a dogfood instance of LaunchDarkly. We use LD as our plan
permissioning system (the plans you see on our pricing page are managed by
LD). We also use it for ops-- we migrated a key piece of our analytics
infrastructure over to DynamoDB, for example, and controlled the rollout of
that via a feature flag.

And of course, we'll launch new features behind a flag. I'll admit that we've
had two or three occasions where we had to hit the kill switch after a deploy,
so I'm rather glad we had a LaunchDarkly for our LaunchDarkly.

[edit] here's a shot of our dogfood instance:
[https://twitter.com/jkodumal/status/717786744750477312](https://twitter.com/jkodumal/status/717786744750477312)

------
misterkwon
can't you just use an open source library for this? how many feature flags
would you even need for this to be worth it?

~~~
eharbaugh
Good question - teams should do what’s best for them based on their resources
and scope of feature flagging needs. Though open source libraries exist,
they're per language (Ruby, Python). We offer support for all major languages
+ iOS. As well, we have environment support and access control levels to use
feature flags effectively throughout development. You can read more here:
[http://blog.launchdarkly.com/enterprise-requirements-for-
man...](http://blog.launchdarkly.com/enterprise-requirements-for-managing-
feature-flags/)

~~~
omegaworks
Any hope for Android support?

~~~
eharbaugh
Yes, we are planning on adding Android this summer. Are you interested in
being a beta user? Write us at support at launchdarkly.com

------
amituuush
do you support single page apps?

~~~
apucacao
Yes we do. Checkout the documentation for front-end flags at
[http://docs.launchdarkly.com/docs/front-end-
flags](http://docs.launchdarkly.com/docs/front-end-flags).

Let us know if you have any questions.

Disclaimer: I'm a front-end developer at LaunchDarkly.

------
vishalsankhla
Looks awesome! How long does it take to integrate?

~~~
pkaeding
It is really quick to get started. You just drop our SDK into your project,
and add a few lines to your code around where you want to toggle. Our docs [1]
give examples in each language that we support.

[1]: [http://docs.launchdarkly.com/](http://docs.launchdarkly.com/)

nb: I'm an engineer at LaunchDarkly

------
kzhahou
In the spirit of the HN community feel, "Show HN" has always been about
personal, side, or small projects. Never a link to a company's page.

~~~
dang
Oh no, that's mistaken. Show HN is for something you've made that people can
try out. The project can be, and often has been, a company with customers.

~~~
kzhahou
Weird, I don't think I'd seen a company's landing page as a Show HN before.

Though the thing I'm picking up might be more the fact that this company
didn't just launch today. I.e., they're not showing us something new today.
Their product has been out for, what, at least a year? So if "Show HN" is ok
here, then really any company's social media person can just repeatedly post
links to themselves...

~~~
dang
No, because (a) it has to be posted by the creator and (b) they can't do it
repeatedly.

