
Feature Flag-Driven Development - mikojava
http://blog.launchdarkly.com/feature-flag-driven-development/
======
nobullet
The problem with FFDD is the code, full of "if"s. Some branches stay dead for
months and years. When a feature is released, the flags need to be deleted and
this becomes a challenging and boring task. Teams usually postpone these
removals, setting the lowest priority. In my opinion, Module Flag-Driven
Development gives much better results. Management agrees which set of features
is released in a group as a module. Instead of "if" or "ifdef" engineers have
a configuration of enabled modules. There is no need to delete a flag.

~~~
jkodumal
I haven't heard of module flag-driven development-- would love to hear more
details.

We manage the cleanup issue by defining a "removal branch" that cleans up the
feature flag at the same time the feature flag is introduced. This sticks
around as a dormant pull request during the lifetime of the flag. It's not
much overhead when this is done early. Cleanup does become painful when the
code's not fresh in your mind.

Note that we do feature branches as well as feature flags-- trunk vs. branch
based development is orthogonal to using feature flags.

~~~
nobullet
'removal branch' is a great approach. Module Flag DD is how I call our
approach :). There is no widespread notion for that .

~~~
swsieber
I would love to see an expanded article on this - it would be great. This
article is basically "Feature flags are great, and we can manage them for
you". I'd love to see an article of "Here's a practical guide to using feature
flags without hurting your codebase"

------
edabobojr
One question/concern I have always had -- Do you have multiple feature flags
in place at once? How do you avoid the combinatoric increase in possible
configurations? If you have feature A and B, what happens if A is turned on
first? If B is turned on first? What if they are both turned on at the same
time?

~~~
jkodumal
We do have multiple feature flags in place at once. Our dogfood server (we use
LaunchDarkly on LaunchDarkly) has about 30 feature flags going at any given
time, and we're a relatively small team (still one standup).

For the most part, flags are independent. When I first started using DVCS
(back in the Bitkeeper days) we all thought that merge conflicts from doing
feature branching would be a headache, but this didn't end up being the case.
I've found the same with feature flags. While it's possible for flags to
interact poorly, or to introduce "dependent" or nested flags, it hasn't been a
problem for us in practice.

This seems to scale, too-- I haven't heard this to be an issue in practice at
larger orgs (Etsy, Netflix, etc.) that do feature flag-driven development.

------
Tiquor
I like how one of the oldest concepts in programming, the ifdef, has now
become (if you read the press) a "revolutionary idea" created by Facebook and
apparently the core of a company's business. I'm only being a little
sarcastic.

~~~
arielweisberg
Being able to merge in progress development to your main branch is an
important part of reducing product in development and reducing cycle time.
When dealing with big features that aren't going to reach a viable end user
visible state for months to years it can be a real challenge especially when
what your are working on feels like a it "touches everything."

This is more than just the technical capability. I've been on teams that
insist they are completely unable to iteratively develop and deliver big
features. As a result you end up with huge impossible to review patch drops at
the ends of months of work behind closed doors. It's a disaster every time.

I'm still struggling to communicate to people how to do it and what the
benefits are.

~~~
Tiquor
I'm well aware of the concept and have been doing this for years in my
company's web apps. My sarcasm comes from seeing this covered as a revolution
in software engineering as opposed to the application of some rather old
concepts with new UI and broader application.

------
tedmiston
I would try it if you had a free tier for testing in dev.

