Can someone help with reassurances and arguments for developers on using GrowthBook on our projects? They are worried that development will take a lot longer and complexity will increase. • They estimate at least 50% extra time for releasing new features because they now need to maintain two different versions of that area and make sure dependencies for both is working. And after having many features released with splittest there can be quite a few of these dependencies running at the same time: bloating the code, making the code more complex, worrying how to find and delete old bits of code from splittests that are finished etc. • Some changed they would not even think about split testing because of the complexity with connecting services etc. Like a new payment system.

Hi Kasper - compared to not using any feature flags?

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?

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

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