I'll be presenting on Track 4 at 2:50pm BST and available live in Slack during my talk. Track 4 is right next to the one that goes to Hogwarts, so don't stand near any brick walls if you get there early. 😏

🚩Catch #xpo-split's session "ADVANCED FEATURE FLAGGING: IT'S ALL ABOUT THE DATA" with @dave.karow @ 2:50 PST / 9:50 EST 🏆Don't forget to enter the Raffle while you are it to learn more about Split: https://try.split.io/does22eu

Happy Wednesday everybody... Here are some of the tips/links I shared in my session today in case you missed it: Q: I’ve never used feature flags in this split / ramping up way rather than just binary on/off. How do you mitigate weirdness when your feature (e.g.) changes the way data is stored in the database between the on and off states? A: additive changes... backwards compatible. If you plan to move from Firstname, Lastname in one column to two columns, you add two new columns and write to all three until you've completed the transition.

New code writing to all three makes backwards compatibility work. Clean up work (backend job that copies the old column to two new columns) is done at your leisure, not during downtime/maint interval. then you can cut over once there's no backlog in the copy job... so it can quickly nail the remaining few as you are ramping up.

https://try.split.io/hubfs/pdfs/oreilly-feature-flag-best-practices/OReilly_and_Split_Feature_Flag_Best_Practices.pdf?utm_source=Trade+Show&utm_campaign=Event_DOES_EU_2022 Pro tip: Chapter 6 in the above e-book is a great reference for flags and data-structure changes

If you were late to the party, here's a very snackable video/blog series on Feature Flags, Progressive Delivery and this approach of using data to make better decisions, improve safety and make every iteration more useful: https://www.split.io/blog/progressive-delivery-safe-at-any-speed-playlist-blogs/

(Above playlist takes ~20 min to watch from end to end)

If you DO know about feature flags and are wondering if there are more things you can do with them, have a look at Joy Ebertz's video: https://www.split.io/resources/flagship-2022/feature-flag-use-cases-you-havent-heard-about-yet/

Agenda from above ^ talk

Great question about tech debt/flag maintenance: Q: on the subject of having quick access to remediation/rollback - when is the right time to remove a feature flag and all the associated “old” code from your codebase? and how do you ensure the “old” code is removed along with the flag? A: one pattern that is useful is to flag at logical module points, not line-by-line. With clean, natural boundaries, you don't have to go through with a fine-toothed comb to find the things to remove later. This blog post, written by one of our Front End and Back-End for Front End lead devs, uses front end JavaScript as an example, but the pattern applies to any codebase. https://www.split.io/blog/manage-feature-flags-javascript/

Commentary on above blog post ^ Sometimes folks want to get very "surgical" with putting a flag at the exact line of code in a module that does the thing... that makes it trickier. Check out David B's example where the other modules are abstracted away enough that they don't know or care what the parts that change/get removed are doing. Quinn Daley [6:12 AM] we have a policy of putting flags at the “entry point” wherever possible, but it’s not universally adopted Dave Karow (Split - Sr. Progressive Delivery Advocate) [6:19 AM] Entry point was exactly the advice I used to give... then David B gave a talk about the modular way he does it and I realized his way was WAY less mentally demanding. After that talk, we convinced him to put it in that blog. They've even built some tooling that makes the modules approach faster/less risky, such as this: > • Adding a feature flag becomes easy. We have a script that will take an existing component, make a second copy of it and set up the toggler function that wraps both. These two benefits are probably my favorite: > • Reasoning about code is very easy. Because these are at “interface boundaries,” you do not have to contend with mixed logic in one routine. From the consumer’s point of view, you don’t know that there are multiple variations. From the consumee’s standpoint, you still do not know that there are other variants of yourself that could be run. This means that when working on one of the component variations, you can focus your attention on that one feature. > • This also makes unit testing dramatically easier. Because the blocks of code being developed are completely distinct, it also means that the unit tests are completely distinct.

Aha experience Quinn had after reading that: > oh nice! I see there’s a subtle difference here and why it’s important

And as I offered during my session: > Feel free to reach out to me on LinkedIn if you still have questions. https://www.linkedin.com/in/davekarow/

Enjoy the rest of your day and remember, we have a full Europe-based team available for questions here! https://members.itrevolution.com/live/split

Hello from Split! We are looking for experts that have used Unleash or Microsoft’s Azure App Configuration (MAAC-FM) product for their feature flag solution to provide feedback on a working prototype we have that integrates feature flags with Split. We would like for you to support us in our research by joining us on a Zoom call where we will ask some questions about your experience with your current feature flagging solution and demonstrate a prototype of early concepts. Session Length: 45 min Who: Azure App Configure - Feature Manager Compensation: $50 Amazon Gift Card If interested, we ask that you fill out https://airtable.com/shr32cXaU9Ohpg1gj and we will get in contact directly if you qualify!