3 ms·

Yah 'supposed', but that's (to me) in the same bucket as 'different features behind flags aren't supposed to interact' and 'we're supposed to have detailed docu

by roel_v 4y ago

Yah 'supposed', but that's (to me) in the same bucket as 'different features behind flags aren't supposed to interact' and 'we're supposed to have detailed documentation of who is/was using what set of features at time x'. That's also what I meant with 'it's all in the process' - if there is good management of all of this, it may work. And I'm sure that for some people, it does actually work. Meanwhile for me, I'm staring at build scripts with 15+ year old feature flags that at this point are realistically never going to be removed, and people still sometimes suggest 'yeah but this one little thing we can put in a custom build until it works for everyone else too...' So now not having feature flags is a hill I'll die on.

capableweb 4y ago
Yeah, but there are lots of things that can be footguns if you use them incorrectly, that's simply a part of the job as a software engineer. Otherwise you could argue that `rm -rf` should be removed as it could potentially delete files if you're not careful, but I haven't seen anyone argue for that instead of arguing for "Do be careful when using rm -rf". Same goes for feature flags, and a ton of other things.
Hermitian909 4y ago
Feature flag systems should have the following features: - Ability in code to set the default value in non-production environments such that if a developer never set the flag, it assumes this default value. When a feature is fully released the default should be "on for everyone", generally with the expectation it will be retired soon. - A required field designating an owner usually a team, but can be a person if your company is small enough - A field in the flag definition for an expected retirement date The defaults keep combinatorial explosion down and the other practices make it easy for one responsible person to audit flags and track down responsible parties.

by roel_v 4y ago

capableweb 4y ago

Yeah, but there are lots of things that can be footguns if you use them incorrectly, that's simply a part of the job as a software engineer. Otherwise you could argue that `rm -rf` should be removed as it could potentially delete files if you're not careful, but I haven't seen anyone argue for that instead of arguing for "Do be careful when using rm -rf". Same goes for feature flags, and a ton of other things.

Hermitian909 4y ago

Feature flag systems should have the following features: - Ability in code to set the default value in non-production environments such that if a developer never set the flag, it assumes this default value. When a feature is fully released the default should be "on for everyone", generally with the expectation it will be retired soon. - A required field designating an owner usually a team, but can be a person if your company is small enough - A field in the flag definition for an expected retirement date The defaults keep combinatorial explosion down and the other practices make it easy for one responsible person to audit flags and track down responsible parties.