3 ms·

My company actually does this - we just found that a) we wanted to be able to tell our clients about new features instead of them “stumbling on them,” which mak

My company actually does this - we just found that a) we wanted to be able to tell our clients about new features instead of them “stumbling on them,” which makes more sense when you’re dealing with low numbers of high value high touch clients; and b) we wanted to have greater confidence that our code was working properly in the absence of a thorough test suite. Feature flags could help with a) and a good test suite would help with b) though.

rco8786 4y ago
To be clear I’m not saying it’s “bad”. Just that the article purports to be about how develop things fast. And purposefully slowing down your releases is not that
- Hnrobert42 4y ago
  With feature toggles, you can deploy continuously, but release weekly.
  - rco8786 4y ago
    Respectfully, that is worse than just deploying once a week (which is totally fine btw. Lots of reasons to do that) You’re still waiting to release features that are done and turning on a whole week’s worth of features at one time, but it’s even worse because you spent a bunch of extra time building it to have feature flags.
    - q7xvh97o2pDhNrh 4y ago
      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

To be clear I’m not saying it’s “bad”. Just that the article purports to be about how develop things fast. And purposefully slowing down your releases is not that

Hnrobert42 4y ago
With feature toggles, you can deploy continuously, but release weekly.
- rco8786 4y ago
  Respectfully, that is worse than just deploying once a week (which is totally fine btw. Lots of reasons to do that) You’re still waiting to release features that are done and turning on a whole week’s worth of features at one time, but it’s even worse because you spent a bunch of extra time building it to have feature flags.
  - q7xvh97o2pDhNrh 4y ago
    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.