This message was deleted.
# announcements
w
This message was deleted.
f
Hi Kasper - compared to not using any feature flags?
There is some increased complexity - but pretty minimal. GrowthBook was designed for a good developer experience- most features can be created with one line
50% is pretty wild
yes, there are some changes which are very hard to do - but for those case, you can decide case by case if you want to deploy it as an A/B test or just change it
its up to the team to figure out if knowing the impact of the change, is worth the complexity of the flag. From my experience, it almost always is.
I would suggest start with a test or two just to see how the team likes it. You don’t have to boil the ocean in one go.
n
Hi Graham. Thank you for your input. Yes, it is compared to not using feature flags. We are also going to do a testrun - finally. Do you have som tips or insights into how to work with the complexity and the dependencies? What are you experiences and how do you tackle them?
f
Yes, if you’re using the Cloud version, we can enable some trial features which will give you real time usage of any flags - and you can remove flags that are no longer being used. Typically if you’re using feature flags for a/b testing, you’ll want to run the test for two weeks or so, and then when you call the test, part of that process is to remove the flag and implement/remove the feature for all. There are some other best practices that we’d be happy to meet your team and discuss. https://calendly.com/growthbook
b
I would say your developers are probably right, but it's a good practice to get into. The Growthbook feature flag checks are a good way to know when there's code to remove - e.g. just searching for
useFeature
or whatever
🙌 1
139 Views