Feature Flag-Driven Development • Hacker News Board

Re: Feature Flag-Driven Development

#11

Post by nobullet » Tue, Nov 03, 2015, 9:54 PM UTC

jkodumal wrote: post #6

nobullet wrote: post #5

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. In…

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. N…

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

Re: Feature Flag-Driven Development

#12

Post by swsieber » Tue, Nov 03, 2015, 11:01 PM UTC

nobullet wrote: post #11

jkodumal wrote: post #6

Earlier quoted context omitted.

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. N…

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

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"

Re: Feature Flag-Driven Development

#13

Post by jkodumal » Wed, Nov 04, 2015, 12:40 AM UTC

edabobojr wrote: post #10

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?

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.

Re: Feature Flag-Driven Development

#14

Post by Tiquor » Sat, Nov 07, 2015, 9:10 AM UTC

arielweisberg wrote: post #4

Tiquor wrote: post #2

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.

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…

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.

Re: Feature Flag-Driven Development

#15

Post by Tiquor » Sat, Nov 07, 2015, 9:10 AM UTC

arielweisberg wrote: post #4

Tiquor wrote: post #2

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.

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…

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.