3 ms·

I think you're correct only in the scenario where the feature-flags are binary on/off switches. The modern "feature flag" is more of a knob that can be slowly

I think you're correct only in the scenario where the feature-flags are binary on/off switches. The modern "feature flag" is more of a knob that can be slowly turned up, along with ideally a way to send shadow traffic through the feature even before any % of real traffic is allowed through. In that proper implementation of feature-flags, the overall benefits (easy rollback, graduated rollout, selective rollout based on user characteristics, better ability to manage scale) outweigh the rather-trivial engineering cost of wrapping a few if-clauses around the feature.

rco8786 4y ago
That does not sound much like a “weekly release” though > rather-trivial engineering cost I personally disagree with this. To implement feature flags your engineers have to reason about all the places where the feature needs to be on/off, implement those flags, write and maintain test cases for both the on and off case, rollout the code, then go back and refactor everything to remove the flags afterwards. It’s not insurmountable. But it’s not trivial in my experience.
- q7xvh97o2pDhNrh 4y ago
  > That does not sound much like a “weekly release” though I respectfully disagree, because I'd say that a "release" ought to be defined from the viewpoint of a given individual user. From that person's perspective, they are indeed seeing things change only weekly, and the details of how that's done (e.g., feature flags vs giant deployments) are mostly irrelevant to them. > It’s not insurmountable. But it’s not trivial in my experience. You are right. Honestly, I'm so used to having to sell the idea that I just reflexively wrote it that way. Thank you for listing out the different pieces. You're absolutely right there is a lot of extra "essential complexity" that gets added in. Even if the "actual" coding work is "just a few" extra if-clauses and tests (which is how I'd sell it ;), everyone has to hold a lot more in their heads. Personally, though, I would still insist that it's way better than the essential complexity that gets added everywhere by coupling "releases" with "deployments." In my experience, once an org lets product-release-tempo dictate engineering-velocity-tempo, the bureaucrats essentially have a chokehold on all engineering decisions. The organization slowly grinds to a halt; high-value customers start getting picked off by nimble, faster-moving startups; and the circle of life continues. Feature flags are IMHO a key technique for a startup-that's-getting-bigger to hold off this particular mechanism of decline. Non-technical stakeholders at all levels can be easily waved off with a simple remark of, "Well, we'll feature-flag it." And engineers can stay much more empowered, even as the company grows much bigger.

rco8786 4y ago

That does not sound much like a “weekly release” though > rather-trivial engineering cost I personally disagree with this. To implement feature flags your engineers have to reason about all the places where the feature needs to be on/off, implement those flags, write and maintain test cases for both the on and off case, rollout the code, then go back and refactor everything to remove the flags afterwards. It’s not insurmountable. But it’s not trivial in my experience.

q7xvh97o2pDhNrh 4y ago
> That does not sound much like a “weekly release” though I respectfully disagree, because I'd say that a "release" ought to be defined from the viewpoint of a given individual user. From that person's perspective, they are indeed seeing things change only weekly, and the details of how that's done (e.g., feature flags vs giant deployments) are mostly irrelevant to them. > It’s not insurmountable. But it’s not trivial in my experience. You are right. Honestly, I'm so used to having to sell the idea that I just reflexively wrote it that way. Thank you for listing out the different pieces. You're absolutely right there is a lot of extra "essential complexity" that gets added in. Even if the "actual" coding work is "just a few" extra if-clauses and tests (which is how I'd sell it ;), everyone has to hold a lot more in their heads. Personally, though, I would still insist that it's way better than the essential complexity that gets added everywhere by coupling "releases" with "deployments." In my experience, once an org lets product-release-tempo dictate engineering-velocity-tempo, the bureaucrats essentially have a chokehold on all engineering decisions. The organization slowly grinds to a halt; high-value customers start getting picked off by nimble, faster-moving startups; and the circle of life continues. Feature flags are IMHO a key technique for a startup-that's-getting-bigger to hold off this particular mechanism of decline. Non-technical stakeholders at all levels can be easily waved off with a simple remark of, "Well, we'll feature-flag it." And engineers can stay much more empowered, even as the company grows much bigger.