Hacker News Reader

Comment by andai | Hacker News Reader

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

View on HN

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.

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.

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.

Which is why SSL certs are now 47 days long or whatever it is.

TLS certs are 200 days (as of last month). Or whatever

https://www.digicert.com/blog/tls-certificate-lifetimes-will...

Reply on news.ycombinator.com