I think what he's saying is from a production standpoint, the new feature is feature-flagged, and that feature flag has the feature disabled. From a test environment standpoint, you can then enable that feature flag/combination of feature flags, test until your heart is content, and only enable in prod if things go pear-shaped. And if they do, well...it can be as simple as turning that feature flag back to disabled, unless state changes prevent that.
Silhouette|5 years ago
For a feature flag to be useful compared to the typical setup where you have a feature branch and then rebase that onto master from time to time until you're ready to do a fast-forward merge, you would need to be testing multiple features concurrently before any of them is merged back to master.
Testing all possible combinations of unmerged features in development is an exponentially difficult problem, so surely no-one is doing that. However, even testing selected combinations still requires someone to be aware of everything that is going on in enough technical detail to highlight potential trouble areas in time to take useful action that would become more difficult once some of those features start to get merged in.
Assuming you have a large enough project that co-ordinating different ongoing development work isn't just handled via informal discussions anyway, that would mean someone has to be identifying risky combinations that could benefit from testing in advance, and someone has to be responsible for doing that testing, and someone has to be responsible for addressing any issues that are discovered as a result. Does anyone here work in a development group that actually does this?
Meanwhile, the cost of using feature flags routinely is clear: every time you do any significant development work, you have to bracket all affected code with a new flag, and someone has to coordinate those flags and make sure they're all tidied up with code left in the "on" mode by release time.