4 ms·

>Much of the time I’m using flags so I can commit unfinished code because I don’t want to create a separate branch and have one source of truth This seems like

>Much of the time I’m using flags so I can commit unfinished code because I don’t want to create a separate branch and have one source of truth This seems like an incident in the making. If each dev on a team commits unfinished code into prod behind flags, the whole project is going to be littered with flags and unfinished code. Some intern is going to delete a flag or an if check and then everything is going to break.

riffraff 3y ago
Why would an intern remove a flag? The flag is not special, it's code like everything else, with tests, ownership, documentation etc.. The idea of the "unfinished code behind a flag" is to be able to work on trunk instead of a long lived branch, increasing the pace of development and reducing integration costs. This works quite well in my experience, and definitely better than "let's keep a huge branch in sync with the main one for 3 months while we finish". The problem IME is the opposite: flags do not get removed fast enough, littering the code past their utility.
hsn915 3y ago
There's nothing special about flags that makes them more likely for an intern to delete by mistake. It's just code. If the team is so bad that an intern can mess things up, they will, and the mess will have nothing to do with feature flags.
- sverhagen 3y ago
  Aren't there common patterns of good "just code" and bad "just code"? I've been told for a long time that global variables are a bad pattern. Maybe feature flags are a bad pattern too. One concern about feature flags is testing, and the added permutations of testing needed to include all the feature flags in testing. You tested with flag A on and off, you tested with flag B on and off, but did you ever test with them both on and both off? Without feature flags, a big change that could have been represented by a feature flag would hopefully have to make its way past some quality gates. With feature flags, the exact permutation that you're going to cause later today by flipping on some feature flags may well not have been tested. Not that forgetting to test is something you can't protect yourself against with tools and processes, but testing all the permutations may be expensive. You may not have to test all the permutations, if you can predict which permutations are relevant for your flipping feature flags later today. But a lot of organizations have poor discipline in cleaning up old feature flags, so it may not be so predictable. Maybe that's not a feature flag problem but an organizational problem, but the feature flags are gonna get blamed at some point, nonetheless.
wingerlang 3y ago
I've worked at a large company where everything was under feature flags, think a dozen teams working on apps alone. We didn't push straight to develop, but we definitely had possibly unfinished code on production. For example a feature could be "done" but a bug was found, and the app was already released. That feature flag would simply not be turned on until the next version where it would be fixed. We had a lot of tests for each feature flag variation, both unit and ui tests. The codebase wasn't "littered" but there definitely existed unused code under flags, either to-be-used, or to-be-deleted. We had a grafana view of experiments that were old and not yet removed to manage them. Overall we never had incidents around this, to my knowledge anyway.
brigadier132 3y ago
> This seems like an incident in the making This is how every major tech company works today.
- clintonb 3y ago
  Not quite. I never used flags to hide unfinished code. I left that on a branch. Feature flags are used to rollout production-ready features. This just seems like taking trunk-based development to an unnecessary extreme.

riffraff 3y ago

Why would an intern remove a flag? The flag is not special, it's code like everything else, with tests, ownership, documentation etc.. The idea of the "unfinished code behind a flag" is to be able to work on trunk instead of a long lived branch, increasing the pace of development and reducing integration costs. This works quite well in my experience, and definitely better than "let's keep a huge branch in sync with the main one for 3 months while we finish". The problem IME is the opposite: flags do not get removed fast enough, littering the code past their utility.

hsn915 3y ago

There's nothing special about flags that makes them more likely for an intern to delete by mistake. It's just code. If the team is so bad that an intern can mess things up, they will, and the mess will have nothing to do with feature flags.

sverhagen 3y ago
Aren't there common patterns of good "just code" and bad "just code"? I've been told for a long time that global variables are a bad pattern. Maybe feature flags are a bad pattern too. One concern about feature flags is testing, and the added permutations of testing needed to include all the feature flags in testing. You tested with flag A on and off, you tested with flag B on and off, but did you ever test with them both on and both off? Without feature flags, a big change that could have been represented by a feature flag would hopefully have to make its way past some quality gates. With feature flags, the exact permutation that you're going to cause later today by flipping on some feature flags may well not have been tested. Not that forgetting to test is something you can't protect yourself against with tools and processes, but testing all the permutations may be expensive. You may not have to test all the permutations, if you can predict which permutations are relevant for your flipping feature flags later today. But a lot of organizations have poor discipline in cleaning up old feature flags, so it may not be so predictable. Maybe that's not a feature flag problem but an organizational problem, but the feature flags are gonna get blamed at some point, nonetheless.

wingerlang 3y ago

I've worked at a large company where everything was under feature flags, think a dozen teams working on apps alone. We didn't push straight to develop, but we definitely had possibly unfinished code on production. For example a feature could be "done" but a bug was found, and the app was already released. That feature flag would simply not be turned on until the next version where it would be fixed. We had a lot of tests for each feature flag variation, both unit and ui tests. The codebase wasn't "littered" but there definitely existed unused code under flags, either to-be-used, or to-be-deleted. We had a grafana view of experiments that were old and not yet removed to manage them. Overall we never had incidents around this, to my knowledge anyway.

brigadier132 3y ago

> This seems like an incident in the making This is how every major tech company works today.

clintonb 3y ago
Not quite. I never used flags to hide unfinished code. I left that on a branch. Feature flags are used to rollout production-ready features. This just seems like taking trunk-based development to an unnecessary extreme.