Hacker News Reader

Comment by thejosh | Hacker News Reader

Yep. And if nobody actually cares about the feature like everyone thought they would, great we didn't waste time. If they hate it (usually through feature flags of product trials), and work needs to be done, simply flip the flag back off.

It's a great way to do small-medium features.

View on HN

No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate different DB schemas / DTOs in addition to the "lol feature flag" on the front end is absurd.

If your feature flags are behind such complexity you have a bigger problem than feature flags.

Note "serious work". If you are hiding a banner, an extra button that calls a service method used elsewhere, some text, etc - feature flag away.

Real world problems tend to be, at the very least, "add some new fields to the form" - at which point you are messing with DB schemas OR following bad practices like making fields that should have no business being nullable accept nulls because "who knows if the feature flag is on". This quickly destroys normalization and data consistency.

Right... which is why I said It's a great way to do small-medium features.

If you want to do rolling/canary deployments without downtime, or gradual rollouts to subsets of users, or a/b testing, you will have multiple versions running in parallel against the same database. Plenty of "serious work" happens that way.

Same problem. Someone I used to work with wrote an article about it and you run into the same problem with A/B tests / canary deployments / etc - need to account for different DB schemas:

https://medium.com/swlh/worthwhile-modern-deployment-strateg...

Reply on news.ycombinator.com