6 ms·

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. Develo

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.

_corym 2y ago
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.
- goosejuice 2y ago
  Sounds like a great reason to include cleanup as part of the initial work.
- willsmith72 2y ago
  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
  - hinkley 2y ago
    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.
millerm 2y ago
Then that is simply a bad lead on the team. "Do your job." (Not you)
wetpaws 2y ago
[dead]
triyambakam 2y ago
In my experience engineers usually want to remove the outdated flags but product does not prioritize that work.
- hinkley 2y ago
  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.
- andruby 2y ago
  We had an experience where it was product that pushed for cleaning up the flags. The best companies I've been at where those where product and engineering really operate as one team.
hinkley 2y ago
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.
- spike021 2y ago
  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.
  - hinkley 2y ago
    The distinction I’m talking about is marking the feature milestone for deployment but not counting the feature as done until the toggle is dispensed with. Either removed, or declared a configuration we intend to keep indefinitely. Admittedly, there’s still a gap there where a toggle may be needed until the end of an initiative (an Epic in Scrum terms) but that’s going to be at least an order of magnitude, and likely 2 orders, fewer toggles to deal with. When the order of magnitude changes so does the solution.
keraf 2y ago
At one of my first jobs, the codebase was massive and feature flags were heavily used. My first task given by my boss was to remove flags that have been enabled in all environments for a while. Great and engaging way to introduce someone to a new codebase, it's relatively easy and can be done with little assistance right of the bat, you also get to commit code in your first days and it reduces tech debt making everyone happy. Been doing that with my new hires in other jobs.
miraantabrez 2y ago
This is one of the reasons we built type-safe feature flags at Hypertune. When a developer deprecates a flag, they get type errors everywhere it's still used. This fails the build so they're forced to remove all the flag references, and they get a nice IDE / compiler driven workflow to do that. Otherwise it's easy to leave flag usages around.

_corym 2y ago

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.

goosejuice 2y ago
Sounds like a great reason to include cleanup as part of the initial work.
willsmith72 2y ago
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
- hinkley 2y ago
  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.

millerm 2y ago

Then that is simply a bad lead on the team. "Do your job." (Not you)

wetpaws 2y ago

[dead]

triyambakam 2y ago

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

hinkley 2y ago
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.
andruby 2y ago
We had an experience where it was product that pushed for cleaning up the flags. The best companies I've been at where those where product and engineering really operate as one team.

hinkley 2y ago

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.

spike021 2y ago
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.
- hinkley 2y ago
  The distinction I’m talking about is marking the feature milestone for deployment but not counting the feature as done until the toggle is dispensed with. Either removed, or declared a configuration we intend to keep indefinitely. Admittedly, there’s still a gap there where a toggle may be needed until the end of an initiative (an Epic in Scrum terms) but that’s going to be at least an order of magnitude, and likely 2 orders, fewer toggles to deal with. When the order of magnitude changes so does the solution.

keraf 2y ago

At one of my first jobs, the codebase was massive and feature flags were heavily used. My first task given by my boss was to remove flags that have been enabled in all environments for a while. Great and engaging way to introduce someone to a new codebase, it's relatively easy and can be done with little assistance right of the bat, you also get to commit code in your first days and it reduces tech debt making everyone happy. Been doing that with my new hires in other jobs.

miraantabrez 2y ago

This is one of the reasons we built type-safe feature flags at Hypertune. When a developer deprecates a flag, they get type errors everywhere it's still used. This fails the build so they're forced to remove all the flag references, and they get a nice IDE / compiler driven workflow to do that. Otherwise it's easy to leave flag usages around.