Feature Flag-Driven Development
blog.launchdarkly.com
Feature Flag-Driven Development
1–10 of 15 posts
Re: Feature Flag-Driven Development
#2I 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.
Re: Feature Flag-Driven Development
#3I 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.
CTO of LaunchDarkly here. We kind of embrace it a little bit-- locavore booleans as a service.
But the real power behind the idea is not the ifdef piece, it's the idea of dynamic, context-aware configuration. You've got a user-friendly tool that can control the code paths being executed in your application without restarts or redeploys.
Re: Feature Flag-Driven Development
#4I 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 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.
Re: Feature Flag-Driven Development
#5The 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.
Re: Feature Flag-Driven Development
#6The 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.
Note that we do feature branches as well as feature flags-- trunk vs. branch based development is orthogonal to using feature flags.
Re: Feature Flag-Driven Development
#7I 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.
CTO of LaunchDarkly here. We kind of embrace it a little bit-- locavore booleans as a service. But the real power behind the idea is not the ifdef piece, it's the idea of dynamic, context-aware configuration. You've got a user-friendly tool that can control the code paths being executed in your application without restarts or redeploys.
Read: it's not ifdefs, it's shiny UI wrapped around them! All well and good (I appreciate a good UI), but certainly not "new."
Re: Feature Flag-Driven Development
#8The 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…
Clever!
Re: Feature Flag-Driven Development
#9I would try it if you had a free tier for testing in dev.
Re: Feature Flag-Driven Development
#10One 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?