A case against feature flags

In my first position as CTO, I was lucky enough to hire all the members of my team.

My first hires were really keen on doing the right thing, and, during their on-boardings, during the first week retrospective one-to-one, two of them wanted to introduce feature flags and feature branches.

A rule of thumb is to avoid feature branches as they slow down the feedback loop.

On another hand, feature flags are still considered as a goal to achieve.

For me, feature flags should be avoided when there is a shortage in manpower, we have a huge workload for a small team, the effort should be put in doing small iterations, not hiding changes behind a dynamic flag.

It is a delusion to see feature flags as a way to deliver faster, it simply increase workload and does not impact the users.

Some argue that they increase stability: it is quite the opposite.

I use to work on product which had more than 120 feature flags, some were always enabled, some other has never been been enabled, some could not be enabled or disabled without breaking the product, some were here for decades.

At this point, it becomes flavors, not feature flags, and they require a long-term strategy.

Note: there might be a will to integrate A/B testing, which is also time-consuming, but doable without features, keeping the same features changing how they are displayed.