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

81–90 of 92 posts

Re: Feature Flags: Theory vs. Reality

#81

Post by victorNicollet »

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's a matter of dev team culture: always leave the code cleaner than you found it. Hire people who understand this, and remind each other through reviews.

As for external pressure from shareholders to skip cleanup: it's better to not describe cleanup as a separate step, but as just another part of feature implementation. It is a fact of software development that work on a feature must be done both before and after that feature is first available in production (whether it's to ensure that all is fine with a finger on the rollback button, to set up relevant production monitoring, or to clean up any scaffolding that was required for the release), and it is possible to have features that are available in production but are not yet _done_. Finishing the work is not optional.

Re: Feature Flags: Theory vs. Reality

#82

Post by IggleSniggle »

q7xvh97o2pDhNrh wrote: post #62
6D794163636F756 wrote: post #35

Earlier quoted context omitted.

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?

> I've at times been told that tech debt is fine because products only last 3-4 years before a replacement gets made. Translating from corp-speak, whoever said that probably meant: "I plan to get promoted before we need to pay this tech debt down."

You also see this corp-speak from devs, although usually in the form of "I plan to get hired somewhere else before we need to pay this tech debt down."

Re: Feature Flags: Theory vs. Reality

#83

Post by IggleSniggle »

6D794163636F756 wrote: post #57
marcosdumay wrote: post #56

Earlier quoted context omitted.

> products only last 3-4 years before a replacement gets made Is that your experience? I imagine it can be a kind of self fulfilling prophecy, but even then I can't imagine people replacing everything each 4 years. And if that's not your experience, then the point is moot.

That's how long it takes before the person who signed off on it has moved to another job and made the product someone else's problem. At that point the new person will usually kick off a new project because the old one is bad and releasing a new product is better for their chances of promotion

I worked at a software shop with very high retention rates (like, 30 years, 10 years on average), and the inverse can also be an issue, "I own this product and it's my problem not yours." Having seen both situations, I personally believe that it can also be that a new project comes to exist simply because the old one is too complicated to understand; some things you need to work through in order to get. Someone here on HN said recently, "people forget that the primary job of the software engineer is as a learning agent for the org" or similar, and the more I see, the more I believe it. I used to think it was all about efficient automation, but I'm not so sure anymore.

Re: Feature Flags: Theory vs. Reality

#84

Post by malfist »

phyrex wrote: post #80
malfist wrote: post #69

Earlier quoted context omitted.

That works for simple on off flags that can wait for a deploy to change. Adding rules on top of that become complex

No, the deploy mechanism is separate from a code deploy. The rules themselves can get very complex and are distributed in the same way

Interesting, I'd like to know more. Is it home grown? Or do you use something COTS?

Re: Feature Flags: Theory vs. Reality

#85

Post by klysm »

DenisM wrote: post #58

Couple of simple ideas for the zombie flag problem: - When adding a flag immediately file a bug to remove the flag by a certain date. Enforce in code review. The bug count will surface the problem to the management. - When a flag is past due date start firing non-fatal incidents. The incident count will also surface the problem to the management.

Agreed surfacing the problem to mgmt is critical, but many mgmt teams do not care about but count

Re: Feature Flags: Theory vs. Reality

#86

Post by phyrex »

malfist wrote: post #84
phyrex wrote: post #80

Earlier quoted context omitted.

No, the deploy mechanism is separate from a code deploy. The rules themselves can get very complex and are distributed in the same way

Interesting, I'd like to know more. Is it home grown? Or do you use something COTS?

It's homegrown. This paper talks about it: https://research.facebook.com/file/877841159827226/holistic-... It also mentions Gatekeeper, which is the rule-based engine I mentioned built on top of it, but there are other feature flag solutions that use configerator for different use cases like killswitches or gradual rollout.

Re: Feature Flags: Theory vs. Reality

#87

Post by malfist »

phyrex wrote: post #86
malfist wrote: post #84

Earlier quoted context omitted.

Interesting, I'd like to know more. Is it home grown? Or do you use something COTS?

It's homegrown. This paper talks about it: https://research.facebook.com/file/877841159827226/holistic-... It also mentions Gatekeeper, which is the rule-based engine I mentioned built on top of it, but there are other feature flag solutions that use configerator for different use cases like killswitches or gradual rollout.

Thank you for that!

Re: Feature Flags: Theory vs. Reality

#88

Post by DenisM »

chrsjxn wrote: post #68
DenisM wrote: post #65

Earlier quoted context omitted.

It’s not forced or high priority - it just surfaces tech debt to management in the way they can easily quantify and prioritize.

Maybe this is just a terminology mismatch, but when you say "incident" that's been a pretty urgent process everywhere I've worked. Other people are talking about breaking CI, which just sounds miserable. Raising awareness to management is great though. Especially if you can quantify it in terms of things that matter to them more than "tech debt". Like startup latency or a direct dollar cost.

Yeah, there should be more than one level of incident severity, this would be on the lower end.

Re: Feature Flags: Theory vs. Reality

#89

Post by JuanPosadas »

MilStdJunkie wrote: post #28

I've got a few friends that work at LaunchDarkly, and from what I can tell, they've got a very good handle on the challenge. Better than the equivalent vendors in my business, anyway. I've had some great talks with the LD people, even though, strictly speaking, I don't get my paychecks from programming, per se. What brought me into the talks was that the feature flag problem is a similar scope to the central one face…

I took one look at their API SDK and could not make heads or tails of it. Not to mention the liability of their service being down or slow one day, or somehow mocking them in our existing test suite. We let our juniors write our feature flag code in less than a day using very simple ORM/SQL and it's just worked.

Re: Feature Flags: Theory vs. Reality

#90

Post by figmert »

JuanPosadas wrote: post #89
MilStdJunkie wrote: post #28

I've got a few friends that work at LaunchDarkly, and from what I can tell, they've got a very good handle on the challenge. Better than the equivalent vendors in my business, anyway. I've had some great talks with the LD people, even though, strictly speaking, I don't get my paychecks from programming, per se. What brought me into the talks was that the feature flag problem is a similar scope to the central one face…

I took one look at their API SDK and could not make heads or tails of it. Not to mention the liability of their service being down or slow one day, or somehow mocking them in our existing test suite. We let our juniors write our feature flag code in less than a day using very simple ORM/SQL and it's just worked.

> We let our juniors write our feature flag code in less than a day using very simple ORM/SQL and it's just worked.

Feature flagging itself is not that hard, it's all the surrounding features that are hard. I can whip up a database engine in a couple of days, but to make it reliable, full of features, and whatever else, will take years.

Post reply on HN