[Techniques] Spikes, spike&stabilize, feature flags about tech-radar HOT 6 CLOSED

We've been doing feature flags for a while now on Figleaf and they've been working well for us - personally I think they should be in Adopt and everyone should be using them. There might be some more issues to figure out - afaik https://github.com/red-gate/SqlClone/pull/1487 ended up as a big feature branch instead of a feature flag because we didn't know how to feature-flag the database - would need to ask the Clone team for more details, though.

We tried to explore a process around spike&stabilize with TODO comments (more details here: [1] [2] [3]). The tl;dr version is that we'd write spikes with TODO comments + dates, and then use a script to scrape the codebase for TODOs older than three weeks and fix any that were still present. After a while we stopped explicitly scheduling old TODOs and now we fix them on a much more ad-hoc basis. I don't think it's been a huge success, but it has partially worked.

I'm not really sure why spike&stabilize didn't work that well for us, but I have some ideas.

• I think the big one we just aren't experimenting/iterating at the pace that Software Faster expects. It sometimes felt like we weren't exercising the option of doing stabilization work because we would always do it, just three weeks later. (I don't have stats for our actual code half-life - I've run git-of-theseus but the stats don't make much sense since we have DMv6 in the same repo - but from Jeff's analysis the average RG tool has a half-life measured in years rather than weeks). I think we might need different processes around product development to really make Software Faster work well (eg do double-diamond from front to back as "experiment, then learn") but that's a huge discussion for another time.
• We also ended up putting off a lot of TODOs repeatedly because they were actually about addressing some future concern (eg "this code will need to be updated when we do X"). These kept popping up in our planning meetings when we were reviewing TODOs and I think they contributed to us getting out of the habit of regularly scheduling TODOs to work on.
• I think we probably still need to work on getting closer to trunk-based development (ie building up code for tasks incrementally rather than having most tasks begin life as a single mostly-complete PR). We sometimes do this well, especially when we explicitly put a feature flag in place first, but we could probably be more consistent about it.

from tech-radar.

Adopt

• Technical Spikes (we do this almost ubiquitously already right?)

Explore:

• Feature - (SQL Prompt team)

I'm not sure if anyone is expressly doing spike and stabilise in the sense that Dan talked about?

from tech-radar.

We've been doing feature flags for a while now on Figleaf and they've been working well for us - personally I think they should be in Adopt and everyone should be using them.

We have been using them for a while as well and my personal view on that is that it works really well and also support short-lived PRs and master being always releasable. @red-gate/spiders any specific views on this?

from tech-radar.

@red-gate/spiders any specific views on this?

Agreed. It's great for keeping feature requests small, getting code into master even before it's ready to expose to customers, and avoiding horrible merge conflicts across long-lived feature branches. At the time when The Spiders were considering adopting them, I did a bit of research across a bunch of teams to work out how they're being used. I could dig out the results, which was really just a description of a feature flag's purpose and life cycle. Might be worth writing that up in our Product Dev area of the info site?

from tech-radar.

Not entirely related to tech radar but I want to put this here so that there is an awareness if anyone else wants to do the same. It would be great to get this in a blog post but only if I had time for everything 😄

We also have a mechanism which integrated feature flags into ASP.NET Core. It takes advantage of ASP.NET MVC Core's action location, config and options mechanisms to hook this into the system in a type safe way. It allows us to:

• Hook the feature flagging into the system with a strongly typed model, which is discovered through the defined convention mechanism: https://github.com/red-gate/SQLEstateManager-vNext/blob/68029f5072392cbe633686f470d70140bcfbd06e/src/RedGate.SqlEstateManager.WebAPI.Core/Features/AuthTokenFeatureFlag.cs
• Feature flag APIs so that they are hidden from the swagger docs and action location: https://github.com/red-gate/SQLEstateManager-vNext/blob/68029f5072392cbe633686f470d70140bcfbd06e/src/RedGate.SqlEstateManager.WebAPI.Core/Controllers/Internal/AuthTokensController.cs#L43
• Enable/disable them through any supported config mechanism such as file config. environment variables, etc.: https://github.com/red-gate/SQLEstateManager-vNext/blob/68029f5072392cbe633686f470d70140bcfbd06e/src/SqlEstateManagerWebAPI/appsettings.Debug.json#L12-L14
• Making feature flags injectable through ASP.NET Core's Options mechanism (e.g. IOptions<AuthTokenFeatureFlag>) so that you can reference these anywhere in the codebase and it would honor the config settings.
• Also push these to the frontend through the APIs: https://github.com/red-gate/SQLEstateManager-vNext/blob/68029f5072392cbe633686f470d70140bcfbd06e/src/WebClient/src/components/Shared/NavigationHorizontal.tsx#L36 so that we can also use these for front end changes.

from tech-radar.

Based on the discussion since @fffej's last comment, I think it's fair to put feature flags into adopt.

from tech-radar.