[hn_throwaway_99]

This misses the point. A big point of feature flags is that you don't yet know how features will be perceived until you get them in front of real users.

I get what you'd like "as an engineer", but it ignores the needs of the business.

[rubicon33]

Isn't that the job a product manager? There are other means and methodologies for gathering user sentiment before you go and build something.

You should get as close as you can, release the product, and iterate.

Todays world is release the product in some ramshackle form or fashion, collect feedback, iterate. To do that introduces a new construct of Feature Flags that would otherwise not be necessary.

[baq]

Yeah product manager says ‘run this on 5% of traffic for 2 weeks and then we’ll see what the next iteration should be’.

[Rapzid]

"Also, if one customer is having a particularly bad time we need to be able to disable the feature for them while continuing to collect feedback from everyone else."

[mrcarrot]

“And management’s priority for Q4 is feature Y, so we’re just going to leave feature X like it is for now”

[rubicon33]

Exactly! And now feature X and the feature flag that governs it is in your code base forever.

In my opinion this all gets back to the way we build product and the expectations we have for our product managers. I have no doubt that their jobs are difficult in many ways, but the lack of actual focus on product specifically as it relates to customer sentiment always strikes me as lazy especially when that data collection is basically passed off to the engineers.

[PH95VuimJjqBqy]

That is not what feature flags are typically used for.

They're typically used as a way of enabling a change for a subset of your services to allow for monitoring of the update and easier "rollback" if it becomes necessary.

They can be used for A/B testing, but this is not what they're typically used for.