Hacker News new | ask | show | jobs
by rubicon33 1006 days ago
As an engineer, I am generally against feature flags.

They fracture your code base, are sometimes never removed, and add complexity and logic that at best is a boolean check and at worse is something more involved.

I'd love a world where engineers are given time to complete their feature in its entirety, and the feature is released when it is ready.

Sadly, we do not live in that world and hence: feature flags.

1 comments

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.

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.

Yeah product manager says ‘run this on 5% of traffic for 2 weeks and then we’ll see what the next iteration should be’.
"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."
“And management’s priority for Q4 is feature Y, so we’re just going to leave feature X like it is for now”
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.

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.