I can guarantee that your codebase is spaghetti of conditional functionality that no developer understands, and that most of those conditionals are leftovers that are no longer needed, but nobody dares to remove.
Feature flags are a good idea, but they require a lot of discipline and maintenance. In practice, they tend to be overused, and provide more negatives than positives. They're a complement, but certainly not a replacement for VCS branches, especially in monorepos.
Not OP, but I think building feature flags yourself really isn’t hard and worth doing. It’s such an important component that I wouldn’t want to depend on a third party
I agree, but it's hard to get the nuances right. It's easy to roll out a feature to half of your user base. It's a bit harder to roll a feature out to half of users who are in a certain region, and have the flag be sticky on them.
We use Unleash at work, which is open source, and it works pretty well.
I generally agree, but see some more nuance. I think feature-flagging is an overloaded term that can mean two things.
First, my philosophy is that long-lived feature branches are bad, and lead to pain and risk once complete and need to be merged.
Instead, prefer to work in small, incremental PRs that are quickly merged to main but dormant in production. This ensures the team is aware of the developing feature and cannot break your in-progress code (e.g. with a large refactor).
This usage of "feature flags" is simple enough that it's fine and maybe even preferable to build yourself. It could be as simple as env vars or a config file.
--
However, feature flagging may also refer to deploying two variants of completed code for A/B testing or just an incremental rollout. This requires the ability to expose different code paths to selected users and measure the impact.
This sort of tooling is more difficult to build. It's not impossible, but comparatively complex because it probably needs to be adjustable easily without releases (i.e. requires a persistence layer) and by non-engineers (i.e. requires an admin UI). This becomes a product, and unless it's core to your business, it's probably better to pick something off the shelf.
Something I learned later in my career is that measuring the impact is actually a separate responsibility. Product metrics should be reported on anyway, and this is merely adding the ability to tag requests or other units of work with the variants applied, and slice your reporting on it. It's probably better not to build this either, unless you have a niche requirement not served by the market.
--
These are clearly two use cases, but share the overloaded term "feature flag":
1. Maintaining unfinished code in `main` without exposing it to users, which is far superior than long-lived feature branches but requires the ability to toggle.
2. Choosing which completed features to show to users to guide your product development.
(2) is likely better served by something off the shelf. And although they're orthogonal use cases, sometimes the same tool can support both. But if you only need (1), I wouldn't invest in a complex tool that's designed to support (2)—which I think is where I agree with you :)
Reminds me of the cable internet I had in college. Every night it would drop for several minutes at a time. My homework included cisco labs using equipment we had to reserve remotely so loosing my SSH connections was maddening.
Numerous phone calls and technician visits. At some point was logging into the cable modem to measure the signal strength. Eventually a tech moved my coax connection at the drop? Problem went away, they said another tech would come back out and check on it.
One week later outages again. Lucky for me they offered one month money back guarantee. I returned that modem on the very last day to the dismay of the receptionist.
Reminds me of a Django project rewrite I got to work on very early in my career. I was able to convince the lead to stave off JavaScript because I could barely read Python at the time. I did however fail to convince my colleagues to write unit tests.
Even at steady state cruising the the tires are flexing and stretching with each revolution. Tires are round but a driveway is flat. If you look at the contact patch of the tire it flattens a bit to confirm to the driveway's shape. Now visualize with each revolution that flatten part of the tire is cycling around the wheel.
