Hacker News new | ask | show | jobs
by skeeter2020 601 days ago
This seems really complex, specifically in the area where I find product, CS & marketing least likely to want it: targeting and controlling their audience. Sounds like a cool thought experiment, fun and challening to implement and not really practical or useful.

If you have a huge userbase and deploy very frequently FFs are great for experiments, but for the rest of us they're primarily a way to decouple deploys from releases. They help with the disconnect between "Marketing wants to make every release a big event; Engineering wants to make it a non-event". I also find treating FFs as different from client toggles is very important for lifecycle management and proper use.

More than the binary nature I think the bigger challenge is FFs are almost always viewed as a one-way path "Off->On->Out" but what if you need to turn them off and then back on again? It can be very hard to do properly if a feature is more than UI, that might cause data to be created or updated that the old code then clobbers, or issues between subsystems, like microservices that aren't as "pure" as you thought.

1 comments

Yes, it's not a good solution. Targeting was missing, good catch. I've just shared an unusual experience to inspire further experimenting.