Comment by andai

18 hours ago

Interesting, from the title I thought it was intentional, as a "forced code review." Apparently not, but now I really like that idea!

5 comments

andai

Reply
jakub_g  10 hours ago

I always wanted to make feature flags system where each FF must declare an expiration date max 1 year in the future and start failing CI beyond that date to force someone to reevaluate and clean up.

It's just too easy to keep adding new feature flags and never removing them. Until one day the FF backend goes down and you have 300 FFs all evaluate to false.

  • fzeroracer  7 hours ago

    We had something like this where I last worked. Whenever we were adding new features or adding things that had potential for significant regressions, we were expected to add feature flags around the change/addition and set an expiration date for three months or so in advance. Once that rolled around, we'd either remove the old path or evaluate if it was necessary to have around as a permanent feature.

    I think it worked out really well even though it increased the administrative overhead. We were always able to quickly revert behavior without needing to push code and it let us gradually shrink a lot of the legacy features we had on the project.

adrianpike  18 hours ago

We've done that at a few places I've been at - it's tricky because if the failure is too short its just annoying toil, but if it's too long there's risk of losing context and having to remember what the heck we were thinking.

Overall it's still net positive for me in certain cases of enforcing things to be temporary, or at least revisited.