3 ms·

I am strongly opposed to feature flags and conditionals in the code, unless absolutely necessary. If you don't remove deprecated features/branches, your code wi

I am strongly opposed to feature flags and conditionals in the code, unless absolutely necessary. If you don't remove deprecated features/branches, your code will end up unmaintainable. If you do remove them, the removal is (in my experience) worse than dealing with merge conflicts. Version control is designed for the exact problem of having multiple implementations exist and merging them as needed. Why roll your own obtuse version control by having all branches in the same file simultaneously when you can just use git to have them exist in parallel universes? There's value in putting a newly completed feature behind a feature flag so you can turn it off instantly in prod. There is much less value in putting dozens of not-yet-functional features behind feature flags that shouldn't be turned on for the next several weeks/months (or maybe never).

liuliu 2y ago
So, I am not doing big development with hundreds / thousands engineers for quite some time. So I started to have sympathy to the other side of the story. The problem with feature branches, especially for frontend development, is that it is never just a "feature" (otherwise, you can gate it compile-time by just compiling out that feature module completely, or in nodejs terminology, treeshaking?). It is a combination of some new UIs, some updates to some interfaces, some new capabilities to a new middleware and some new APIs to call backend. And you don't want to gate these behind a feature flag. And merging these into main branch while make sure when multiple person working on a feature branch know what commits they did on feature branch is in main branch and why a merge from main branch would just absorb these commits are tiring. In these cases, trunk based development is really working for cases that not every developer is a git guru and can just navigate the merge back forth from main branch to feature branch and back. Yes, for these, subversion / perforce makes more sense, but everyone who is not git guru is still on git. That coupled with inefficiencies of your CI system only runs on main branch and needs manual adjustment to run on a feature branch every time, it is easier to do it on the trunk. Every problem is a tools problem, and people picks least resistance to make tools do what they want. There is no right or wrong, pick your poison wisely.
vishnugupta 2y ago
> Why roll your own obtuse version control This is exactly it. Feature flags sounds really good until one realizes that they have all the requirements of a version control. So much that it was even a running joke at Uber that one starts building feature flag and ends up with a version control. The cruft of feature flag also makes it really hard to understand while reading a code, there’s a combinatorial explosion.
sunshowers 2y ago
> Version control is designed for the exact problem of having multiple implementations exist and merging them as needed. This is a common misconception! The primary purpose of version control is to answer discovery requests when the lawyers come knocking. :) (I'm only half joking here. I do think VCS merges are generally not a good idea, for technical reasons like criss-cross merges being an issue.)
prpl 2y ago
There are tools that exist to clean up old flags, but of course you need to know they should be retired (if always off)or integrated into the baseline code (if always on)

liuliu 2y ago

So, I am not doing big development with hundreds / thousands engineers for quite some time. So I started to have sympathy to the other side of the story. The problem with feature branches, especially for frontend development, is that it is never just a "feature" (otherwise, you can gate it compile-time by just compiling out that feature module completely, or in nodejs terminology, treeshaking?). It is a combination of some new UIs, some updates to some interfaces, some new capabilities to a new middleware and some new APIs to call backend. And you don't want to gate these behind a feature flag. And merging these into main branch while make sure when multiple person working on a feature branch know what commits they did on feature branch is in main branch and why a merge from main branch would just absorb these commits are tiring. In these cases, trunk based development is really working for cases that not every developer is a git guru and can just navigate the merge back forth from main branch to feature branch and back. Yes, for these, subversion / perforce makes more sense, but everyone who is not git guru is still on git. That coupled with inefficiencies of your CI system only runs on main branch and needs manual adjustment to run on a feature branch every time, it is easier to do it on the trunk. Every problem is a tools problem, and people picks least resistance to make tools do what they want. There is no right or wrong, pick your poison wisely.

vishnugupta 2y ago

> Why roll your own obtuse version control This is exactly it. Feature flags sounds really good until one realizes that they have all the requirements of a version control. So much that it was even a running joke at Uber that one starts building feature flag and ends up with a version control. The cruft of feature flag also makes it really hard to understand while reading a code, there’s a combinatorial explosion.

sunshowers 2y ago

> Version control is designed for the exact problem of having multiple implementations exist and merging them as needed. This is a common misconception! The primary purpose of version control is to answer discovery requests when the lawyers come knocking. :) (I'm only half joking here. I do think VCS merges are generally not a good idea, for technical reasons like criss-cross merges being an issue.)

prpl 2y ago

There are tools that exist to clean up old flags, but of course you need to know they should be retired (if always off)or integrated into the baseline code (if always on)