Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Feature Flags: Theory vs. Reality

bpapillon.com

Post reply on HN
Print view View original

31–40 of 92 posts

Re: Feature Flags: Theory vs. Reality

#31

Post by esafak »

masklinn wrote: post #27
esafak wrote: post #22

Earlier quoted context omitted.

You can but transparency is a good thing, and if you see it you can fix it before your manager chides you.

It assumes management gives a rat's ass about it. In the original comment: > Especially if their PM leaned on engineers to make the experiment "quick n dirty" and therefore hard to clean up. The PM then just needs to say that they don't have the time to cleanup because they have shit to do, and there's folks out there who pretty much live for this, and are usually well seen by management because they're management's…

The PM is not the EM. Accountability is driven by the org head through the EM. If none of them care then this system will not work of course.

This system is good because it gently targets multiple stakeholders.

Re: Feature Flags: Theory vs. Reality

#32

Post by JohnFen »

esafak wrote: post #22
JohnFen wrote: post #20

Earlier quoted context omitted.

Ahh, so the real target for such an email is management rather than the rank and file? That makes more sense. But surely, it would be better to send email just to those people and put the data up on the company intranet for those devs who are curious.

You can but transparency is a good thing, and if you see it you can fix it before your manager chides you.

The point that I was making is that email might not be the best way of distributing this generally, because in many companies (and most of the larger ones), there is a high rate of companywide emails that amount to just spam. This increases the chances that these particular emails will get mentally categorized the same way and ultimately ignored.

I know that I delete unread about 80% of the internal company emails I get because they're not actually useful, and have better uses for my time.

An email like this, assuming that my own projects are not often mentioned in them, would rapidly get ignored, I imagine.

If the goal is to have the affected teams alerted to the situation, it seems like it would be better distributed directly to the teams individually (a targeted email just to the teams involved) rather than spammed to all of the devs in the organization.

Re: Feature Flags: Theory vs. Reality

#33

Post by SketchySeaBeast »

jpdaigle wrote: post #30
zero_shift wrote: post #4

I've definitely lived with the zombie flags problem. Teams ship experiments that double the size of a piece of code, but never go back to refactor out the unused code branches. In shared codebases this becomes a nightmare of thousands of lines of zombie code and unit tests. This is a social problem as much as a technical one: even if you have LaunchDarkly, DataDog etc making very clear that a flag isn't used, getting…

The tricky requirement that ends up existing and torpedoing attempts to clean up feature flags is a requirement for long-term holdback. e.g. "Test was successful so it's rolling out to all users, minus a 0.5% holdback population for the next 2 years" This then forces the team to maintain the two paths for the long-term, ensuring the team might get re-orged / re-prioritize their projects sometime a year later making t…

> "Test was successful so it's rolling out to all users, minus a 0.5% holdback population for the next 2 years"

Man, I couldn't imagine being a user in such a situation. "Oh, I guess I'm just not getting the better functionality?" Even worse if I were a paying customer.

Re: Feature Flags: Theory vs. Reality

#34

Post by morgante »

It seems like one of the biggest problems is prioritizing the cleanup of old flags. I know some companies have developed tools like Piranha[0] to automate this process and a few of our customers at grit.io have used it for that as well.

Would love to hear if others have had success with automated flag cleanup.

Re: Feature Flags: Theory vs. Reality

#35

Post by 6D794163636F756 »

marcosdumay wrote: post #21
zero_shift wrote: post #4

I've definitely lived with the zombie flags problem. Teams ship experiments that double the size of a piece of code, but never go back to refactor out the unused code branches. In shared codebases this becomes a nightmare of thousands of lines of zombie code and unit tests. This is a social problem as much as a technical one: even if you have LaunchDarkly, DataDog etc making very clear that a flag isn't used, getting…

> getting a team to prioritise cleanup is difficult This is the limitation that breaks every development practice people come up with. That idea of formalizing the cleanup and requiring it for deployment is very interesting. It may be possible to extend it to other contexts.

It runs counter to the pressures a developer faces. I've at times been told that tech debt is fine because products only last 3-4 years before a replacement gets made. When you're on that timeline who cares if you've cleaned up after yourself?

Re: Feature Flags: Theory vs. Reality

#36

Post by jerf »

This is not a complete solution, but it seems to me an aspect of the solution is similar to the way the programming world over the past 5-10 years has been acknowledging that dependencies carry a certain cost with them that must be accounted for. Feature flags do too. If you account for them as just the in-the-moment costs of adding a flag for something, then you are grotesquely underestimating their costs.

Personally I tend to resist them, for much this reason. I don't mean that I never use them and you can't find any in my code, but I resist them. They need to prove their utility to me before I add them, in much the same way I tend to make dependencies prove their worth beyond some momentary convenience before they are allowed in. There are times they leap that bar, but I think that generalized resistance has helped keep the code bases in better order than they otherwise would be. I've seen other teams who did not resist and they've developed a proliferation problem.

Re: Feature Flags: Theory vs. Reality

#37

Post by Brian_K_White »

SketchySeaBeast wrote: post #33
jpdaigle wrote: post #30

Earlier quoted context omitted.

The tricky requirement that ends up existing and torpedoing attempts to clean up feature flags is a requirement for long-term holdback. e.g. "Test was successful so it's rolling out to all users, minus a 0.5% holdback population for the next 2 years" This then forces the team to maintain the two paths for the long-term, ensuring the team might get re-orged / re-prioritize their projects sometime a year later making t…

> "Test was successful so it's rolling out to all users, minus a 0.5% holdback population for the next 2 years" Man, I couldn't imagine being a user in such a situation. "Oh, I guess I'm just not getting the better functionality?" Even worse if I were a paying customer.

You are probably the lucky elite who got to keep the functionality you wanted.

Re: Feature Flags: Theory vs. Reality

#38

Post by adamesque »

SketchySeaBeast wrote: post #33
jpdaigle wrote: post #30

Earlier quoted context omitted.

The tricky requirement that ends up existing and torpedoing attempts to clean up feature flags is a requirement for long-term holdback. e.g. "Test was successful so it's rolling out to all users, minus a 0.5% holdback population for the next 2 years" This then forces the team to maintain the two paths for the long-term, ensuring the team might get re-orged / re-prioritize their projects sometime a year later making t…

> "Test was successful so it's rolling out to all users, minus a 0.5% holdback population for the next 2 years" Man, I couldn't imagine being a user in such a situation. "Oh, I guess I'm just not getting the better functionality?" Even worse if I were a paying customer.

It’s actually usually the paying customers asking via support to be added to the holdback, improved experience or no.

This is more true for larger flags that substantially change the experience and may not implement niche or edge-case functionality. Obviously you want to avoid these kinds of tests if possible but it’s not always possible.

Re: Feature Flags: Theory vs. Reality

#39

Post by stillbourne »

I work at truckstop.com and I came up with a way of managing feature flags that isn't madness. First I used the feature flags in conjunction with module federation. Then I create 3 flags per product, alpha, beta, rc. They looks something like this: mfe-load-search-alpha. The flags are managed by split.io and then tied to a federated endpoint deployment. Which flag gets loaded is determined by a router factory that selects the route with the correct federated endpoint based on the splits. That effectively allows me to decouple a deployment from a release.

Re: Feature Flags: Theory vs. Reality

#40

Post by brightball »

zero_shift wrote: post #4

I've definitely lived with the zombie flags problem. Teams ship experiments that double the size of a piece of code, but never go back to refactor out the unused code branches. In shared codebases this becomes a nightmare of thousands of lines of zombie code and unit tests. This is a social problem as much as a technical one: even if you have LaunchDarkly, DataDog etc making very clear that a flag isn't used, getting…

I've seen that easy enough to address with a frequent review (quarterly, per PI, monthly, etc). If you're operating in some methodology that has a consistent cadence, it should be manageable but you do have to be deliberate about it.

Doesn't take long.

Post reply on HN