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

Show HN: Dorkly – Open source feature flags

github.com

Post reply on HN
Print view View original

51–60 of 104 posts

Re: Show HN: Dorkly – Open source feature flags

#51

Post by hinkley »

alexchamberlain wrote: post #6
snapcaster wrote: post #5

If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been

I think the idea is that it's a separate flags repo?

That’s really an 80/20 situation. The flag repo fixes several large problems around visibility, coordination and state tracking of flag status, but introduces more friction into the system.

I’m not sure I have a comprehensive solution. I just know which ones I hate more than which others. The repo is the least obnoxious of the options.

Re: Show HN: Dorkly – Open source feature flags

#52

Post by hinkley »

kageiit wrote: post #30

Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.

At the risk of sounding like a broken record, I think this is a problem that is compatible with Kanban and incompatible with Scrum. The end of sprint encourages people to mark a task as done that still has several steps and about eight business days before it’s “Done”. But WIP limits in Kanban could be tweaked to account for this and I believe still provide the correct sort of pressure for you to finish what you started before starting something new.

In Limited Work In Progress (LWIP aka WIP-Limited) processes, if you are blocked on your story you help someone else get unblocked on theirs. And then escalate if there is no movement.

Re: Show HN: Dorkly – Open source feature flags

#53

Post by hinkley »

triyambakam wrote: post #38
kageiit wrote: post #30

Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.

In my experience engineers usually want to remove the outdated flags but product does not prioritize that work.

I have found it very professionally unsatisfying to have a clear and documented reason I was unable to code up to my own standards. It doesn’t help of it’s somebody’s fault or everybody’s fault instead of just mine. It might actually be more upsetting, but I’d have to reflect more on that.

At the end of the day it’s still fuckery I was unable to avoid.

Re: Show HN: Dorkly – Open source feature flags

#54

Post by hinkley »

willsmith72 wrote: post #46
_corym wrote: post #32

Earlier quoted context omitted.

My team leverages feature flagging heavily. Developers want to clean them up but product doesn't prioritize the tickets, and it creates more burden for QA as well having to do a full regression test.

The issue is not about feature flags then. It's stakeholders not giving engineers necessary time for upkeep, probably caused by engineers lacking ownership, or failing to communicate

It’s a system where engineers are signing off on work that isn’t actually complete. Which is a problem we had in Waterfall and mostly solved in Agile, except for feature toggles.

Re: Show HN: Dorkly – Open source feature flags

#55

Post by hinkley »

ripperdoc wrote: post #21

Not directly related to Dorkly, but we've implemented feature flags (with our own system) and found them not super-useful and was hoping for more - but we may be doing it wrong. I can certainly see feature flags working well for us when activating e.g. new mostly UI-related features, but when many services and APIs need to change in unison for new features it seems a lot harder to use feature flags in practice. Then…

Last time I did this, we ended up routing our flags through a reloadable config system which used Consul for distribution.

We almost never shared flags across our fairly chunky servicees. We usually found a softer way to do it.

Even with Consul, you can still have enough skew that a few requests in the middle might see A and !A if your request rate is high enough. So it depends on your business model and architecture if that’s acceptable.

Re: Show HN: Dorkly – Open source feature flags

#56

Post by hinkley »

viraptor wrote: post #26
ripperdoc wrote: post #21

Not directly related to Dorkly, but we've implemented feature flags (with our own system) and found them not super-useful and was hoping for more - but we may be doing it wrong. I can certainly see feature flags working well for us when activating e.g. new mostly UI-related features, but when many services and APIs need to change in unison for new features it seems a lot harder to use feature flags in practice. Then…

You need to organise your features in a way that these are not a problem. Need different dependencies - load both. Need a different schema - write both versions, drop old later. Need new services/APIs - feature flip only the user-visible one. The flags are really useful for things like enabling just a fraction of traffic, or ensuring you can switch a feature off much quicker than a full deploy would take.

Everyone laughs when I say this but pull up a thesaurus. When you change the semantics of a thing, you have to change names to have old+new live at the same time. Don’t trust your mastery of English (especially if it’s your second language). There’s a synonym out there that describes the new behavior as well or even better.

Re: Show HN: Dorkly – Open source feature flags

#58

Post by bottd »

hinkley wrote: post #49
wfme wrote: post #41

Earlier quoted context omitted.

There are more options than store in git, or flip willy nilly. For systems of sufficient scale, it's fairly standard to keep flag changes outside of git so that they can be flipped without a pr. That way the flag change UI can apply other validation steps before any change is attempted such as ensuring valid enrolment ranges (no accidental overlap, and no accidental rollouts to 100% instead of 10%), and the associate…

But it’s also common to stick those flags back under some sort of audit system so we know why and how weird states got set. The simplest way is a separate repo with simpler rules for pushing to master. Though you could also create your own audit system (just make sure it functions even when the entire site is down)

This is all decided by business needs, not by engineer preference. If devs aren’t pulling the levers it is good to expose them in an accessible interface, not plaintext.

Re: Show HN: Dorkly – Open source feature flags

#59

Post by spike021 »

hinkley wrote: post #52
kageiit wrote: post #30

Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.

At the risk of sounding like a broken record, I think this is a problem that is compatible with Kanban and incompatible with Scrum. The end of sprint encourages people to mark a task as done that still has several steps and about eight business days before it’s “Done”. But WIP limits in Kanban could be tweaked to account for this and I believe still provide the correct sort of pressure for you to finish what you star…

As someone whose current team process is Kanban and a previous team were also, tech debt like this still inevitably piles up. Sure maybe you can squeeze some time in but even getting a week to spend solely on cleanup is rare, if it comes up at all.

Re: Show HN: Dorkly – Open source feature flags

#60

Post by teeray »

randerson wrote: post #48
drichelson wrote: post #12

Earlier quoted context omitted.

The PR is optional, but governance often requires documented peer approval for all production changes. Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks. >might as well just change the code at that point If changing the code, running tests, building, and deploying is quicker and less risky then…

The sole reason I like feature flags is that I can quickly toggle off a change if it causes a problem. I'd hate to need to find someone to sign off on restoring service. Anything more than 1 or 2 clicks is just adding precious seconds to an outage. I've worked at places that gave broad implicit approval to developers to toggle away as needed. It worked well.

> I'd hate to need to find someone to sign off on restoring service.

In these shops, this gets handled via paging on-call engineers. The on-call is sometimes given more latitude if their actions are auditable.

Post reply on HN