Naming
Show HN: Dorkly – Open source feature flags
31–40 of 104 posts
Re: Show HN: Dorkly – Open source feature flags
#32Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.
My team leverages feature flagging heavily. Developers want to clean them up but product doesn't prioritize the tickets, and it creates more burden for QA as well having to do a full regression test.
Re: Show HN: Dorkly – Open source feature flags
#33Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.
Then that is simply a bad lead on the team. "Do your job." (Not you)
Re: Show HN: Dorkly – Open source feature flags
#34Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.
[dead]
Re: Show HN: Dorkly – Open source feature flags
#35If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
So you just flip feature flags in prod all willy nilly? No process?
Re: Show HN: Dorkly – Open source feature flags
#36If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
Two things,
1. The time to delivery is potentially much much shorter.
2. There's a built-in rules engine for targeting. You could integrate this in! But it feels nice having it separate.
Re: Show HN: Dorkly – Open source feature flags
#37If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
It's good to have the current state of all the flags in source control, just like you do for things like infrastructure-as-code.
The distinction is that you have a different release process, or build a different artifact, from your main codebase. The codebase you are controlling with flags doesn't change when your flags do. This can be done with separate repos if you want one build per repo, but it doesn't have to be.
Re: Show HN: Dorkly – Open source feature flags
#38Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.
In my experience engineers usually want to remove the outdated flags but product does not prioritize that work.
Re: Show HN: Dorkly – Open source feature flags
#39If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
So you just flip feature flags in prod all willy nilly? No process?
You're missing the parent's point. It's not about lacking a change control process, but about having the ability to instantly change the state of a flag when necessary. Moreover, these two can coexist effectively.
Re: Show HN: Dorkly – Open source feature flags
#40If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
It could probably be in a separate repository with access controls and/or deployment lifecycle.
In particular, a change to the yaml for feature flags could bypass most of your build and test pipeline, and changes could be deployed more quickly.
OTOH, you still need to figure out a deployment strategy for it.