[nobullet]

The problem with FFDD is the code, full of "if"s. Some branches stay dead for months and years. When a feature is released, the flags need to be deleted and this becomes a challenging and boring task. Teams usually postpone these removals, setting the lowest priority. In my opinion, Module Flag-Driven Development gives much better results. Management agrees which set of features is released in a group as a module. Instead of "if" or "ifdef" engineers have a configuration of enabled modules. There is no need to delete a flag.

[jkodumal]

I haven't heard of module flag-driven development-- would love to hear more details.

We manage the cleanup issue by defining a "removal branch" that cleans up the feature flag at the same time the feature flag is introduced. This sticks around as a dormant pull request during the lifetime of the flag. It's not much overhead when this is done early. Cleanup does become painful when the code's not fresh in your mind.

Note that we do feature branches as well as feature flags-- trunk vs. branch based development is orthogonal to using feature flags.

[nobullet]

'removal branch' is a great approach. Module Flag DD is how I call our approach :). There is no widespread notion for that .

[swsieber]

I would love to see an expanded article on this - it would be great. This article is basically "Feature flags are great, and we can manage them for you". I'd love to see an article of "Here's a practical guide to using feature flags without hurting your codebase"

[codazzo]

Clever!