Dorra Bartaguiz - Le feature flip pour réussir à avoir du flow

[00:00:03] Hello everyone. I hope you are better than me, in any case. I'm a little sick, so I'm trying to keep up the pace but it's going to be fine. Welcome to my session, how to improve the implementation of feature flipping. Who has already used feature flipping or flippers, we could say in general? Perfect.
[00:00:28] Okay. There are quite a few people. So, uh, I always like to introduce myself first. My name is Dora Bartaguis, I'm a Philly back at Arola, so I'm part of Arola's technical direction. I am also the co-author of a book called Software Craft, published by Dunod, and I wear several hats since I've been a dev for over 16 years now, and I mainly do consulting and coaching missions currently. So there you go. And I was also a teacher at an engineering school in Paris. What is Arola? It's a Parisian ESN, we have a booth if you want to come and talk more about it. But we mainly do technical assistance, consulting, coaching, and we are also a training center for everything related to craft. So TDD, the practices we know, TDD, BDD and Domain Driven Design, but also beyond all that is also technical compared to dev. I wanted to start because I hadn't necessarily planned this talk before, and in fact everything started on X, Twitter. By a discussion or rather a question from Jordan, at the time, he was asking what our feedback was regarding feature flipping. And my answer was a bit negative for some, because I considered it a smell. And so, after a long discussion on Twitter, as usual. I proposed, finally I promised an article to talk about it, and then Yannick contacted me, one of the organizers of Floken, who told me, "Well, I'd like to talk about it because it would be an interesting topic for Floken." And apparently I sold the subject well, so I'm here.
[00:02:18] There you go. So from that moment on, uh, I started working. Uh, I started by sketching a bit what I was going to talk about. And then I also proposed the topic in what we call our open forums at Arola, quarterly. These are spaces, I suppose you know what an open forum is, it's un-conferences, there's no planning scheduled during the day. And then in parallel with that, I launched a survey. I don't know if you saw it on LinkedIn, Twitter or other networks. Don't hesitate to continue participating if you want. Uh, so from these two inputs, uh, I started to do a real research, well, a real research work. Not in that sense, but we're not far off. So I wanted to thank all the people who participated in the survey, whether through direct or indirect answers, and all the Arolians who also enriched this talk. And to come back to the survey, effectively, there were 92 people who knew, uh, 92% of the people who already knew about feature flipping, because it was the first question of the survey. And there was a kind of consensus on the definition. Uh, first, before moving on to the definition, I want to first go through the names used, because we always talk about feature flipping. But there are several names. We talk about flipper, flag, toggle, switch, conditional feature. I don't know if all these words mean anything to you. Probably. And what is feature flipping? It's I activate, I deactivate a feature in time, in real time without delivering code. That's the goal. So what does that mean? It means that I need what we call multiple activation of the same feature. So it's deactivated, I activate it, I deactivate it for a certain time, I activate it and then I deactivate it and so on. Just like the electricity in the house. So you have the switch, it's your flip or flipper, rather, or toggle or flag. So when it's a small feature, like a room, it will be the switch that is your flipper. At the house level, it will be in the electricity panel. When it's a building, it will rather be the electrical panel or the energy distribution board. And then, rather, we are no longer in a feature but rather an epic. And there, clearly, we are no longer in a feature. Nor an epic, for that matter. Uh, the first time I saw, uh, feature flips, like most of us, I suppose, it was on a mission. So I arrive on a mission, they explain to me that all the features we are going to develop, we must have a toggle or a flipper before even thinking about implementing something. And the goal is to deliver it, at least deactivated, and then activate it if necessary.
[00:05:27] And so we had, for each, how to say, for each feature, an associated flipper, which was configured in the base and we activated or deactivated it. And my first question was, why were we doing that for all features? Because normally, once a feature is specified, identified, there's a need behind it, which is that we need to activate it in production. So why were we doing it in all features? And the answer was: Even better. We've always done it this way. Classic.
[00:06:02] So, in fact, my reaction was, if we need to do it all the time like that, it's because the need is not really clear. Or at least, we haven't really identified if we need a feature flip or flipper for that case. And the more time passed, the more I realized that the way we were using feature flippers wasn't necessarily the best. And so there was still potentially some work to be done. And so I started to get into it. And I started to dig a little into the project I was already on, by analyzing all the feature flippers we had, and looking at the number of active features versus inactive ones. When was it put into production? Was it actually deactivated at some point? Is there a difference between environments? Is there a cleanup done in relation to the flipper? Because I suppose that once we've activated it in production, there's no longer any need to have that flipper. We are confident with the version we're going to deliver. And, uh, at the end of the day, it was a bit of a mess. A mess because...
[00:07:18] In fact, actually, the use of flippers was not adapted to our needs. At least, at the time of the team, well, in the team I was in. And then there were a lot of drawbacks that came with precisely the implementation we were doing with feature flipping. The first is that the flippers were not removed. Then there were multitudes of ifs and configs to manage. I'll let you imagine a little bit of the code. So the code became less readable, we no longer knew what was the business if of the technical configuration if compared to the flipper, and then the additional analysis cost. That is, if I do my feature and then it overlaps with another flipper, what is the impact behind it? If I deactivate that one and reactivate the other, how does that work? So we really had a lot of, an additional analysis cost to do, so as not to end up deactivating a feature and then a part of that feature is linked to another flag or another toggle on the other side, and we're a bit confused.
[00:08:25] And so that's the dependency of the flippers, and then after that there's also the problem of tests. So whether it's on the dev side or the QA side, we had non-regression tests to do each time in off-on mode for all the flippers we had in the base. So we had to pay attention to all that.
[00:08:46] If we take an example, imagine that the rectangle corresponds to a scope in the code and, uh, it's to activate a feature, a flip, uh, a feature, sorry. So sometimes we have the same feature but in two places in the code, so we have an if that wanders in one corner and then another on the other side, and then we add ifs and then we have a lot of ifs everywhere. Uh, knowing that it overlaps and so on. And often we have code that looks like this: uh, if my feature is enabled, then, and I also have a business constraint with it, then I do that. Which means that we can no longer distinguish whether it's a purely business condition or a condition with a flipper behind it. So when we try to identify that in a separate method, we get out, but often it's a bit of a mess. Which means that in the end, we end up with developers, male and female, who are either sad, or downright angry, and then, uh, those who are good, well, they desert. They leave the projects because it's a mess.
[00:09:56] So what I propose is, first of all, why do we need to use feature flipping? So, from experience, I found or listed three cases. Uh, so partial delivery, that means we can't deliver the feature during the iteration, if we're on a sprint, or during the defined time. And, uh, we still have to deliver code, because we don't want to have the branch that lasts over time. Uh, there's activation according to context, so we activate functionalities according to segments, it can be the zone, a context, an environment, etc. And then external dependency. External dependency means that we probably have a service to manage, well, that we use, in any case, or that is managed by another team, so it's not within our perimeter and we don't have control over it. And so we're going to put a flipper to say, well, if the service tends not to necessarily be up all the time, well, I deactivate my feature because I depend on this external service. And so I also asked the question in the survey to try to make sure that I'm, well, it's not just in my head, we could say.
[00:11:13] And indeed, there are 29% who consider that the feature never holds on an iteration. There are 27% who, those who responded that they use the flip to activate functionalities by segment, zone, etc. So by context. And 14% consider that several are better to develop in parallel. So several people who work on the same feature and therefore in order not to step on each other, we will create flippers. And what surprised me is that there are 10% who consider that they test in production. It's also linked to, we don't have time for tests. So we have to deliver. But in any case, when we deliver in production, what does that mean? It means that we want to deliver, we're going to deliver the feature deactivated, we're going to activate it, and then we test in production, and if there's a bug, we deactivate it.
[00:12:10] We're going to correct it and then it's off to the races.
[00:12:16] And so that's the cycle we're going to use because we don't have time to test, to potentially have a test phase, and so we're going to test directly in production.
[00:12:29] But in addition to that, thanks to the survey, I had other cases. Uh, other cases, uh, I listed three, but there are still others. But the three main ones are Trunk Based Development, I don't know if you know it.
[00:12:49] I, I'll present it just after. And then the second case is we have a product that is being refactored, and so we have the old version and the new version, and we try to create flippers precisely to activate or deactivate depending on deliveries, and then a case where it's an explicit client request. I have no say, it's imposed on me, and that's it.
[00:13:15] Do you have other cases, maybe?
[00:13:19] No. So if I summarize, on the one hand we have use cases, like partial delivery, activation according to context, external dependency, etc., but also behind it, we have the disadvantages of everything that is feature flipping. The multitude of ifs in the code, so the code is illegible, the additional cost of analysis, etc. And so that's why I invite you today to, uh, see things differently and really ask yourself, ultimately, the question: do I need this feature flip or not? And so I'm going to, throughout the talk, there will be several alternatives, there will be organizational, prioritization, design also, etc. So I'm going to start with, precisely, Trunk Based Development. I asked you the question, do you know it or not? Who knows it? Ah, quite a few. Do you use it every day, or just someone who uses it every day?
[00:14:27] Okay, four, five people.
[00:14:31] What is it, for those who don't know, it's actually a development approach that will invite you, in any case, to contribute directly to a common trunk. So we don't have a branch. Everyone develops on the main branch, we could say. The single branch, and it's the one that will be deployed each time. What's the advantage? It's that, first, we have continuous collaboration, so developers, male and female, work together, and so that necessarily favors communication and collaboration between team members.
[00:15:05] Uh, we don't need, therefore, to separate, well, we have, in any case, the information of everything that happens on the project. We are not in silos, several teams each apart. Uh, second advantage is that it reduces conflicts. Uh, or at least linked to, we'll see later when we have several branches. But in any case, it drastically reduces the number of conflicts we're going to have. Since we're always up to date, ultimately. And then, uh, it also favors continuous integration, since it's naturally facilitated, uh, since the devs develop directly on the common trunk. And so there's no difference, my branch is old and it will have to be updated before merging my branch on the main.
[00:15:58] And then, there's the speed of deployment. No need to release a release branch for those who use Gitflow for example, at what point will I deploy etc. I know that the last commit made, hop, I deliver that. You understood, Trunk-based development is a reaction to branch-based development that you potentially know. Which is simply, I create a branch per feature. So I have my main branch there, and from the moment I create a new feature, I create a branch.
[00:16:38] And finally, it happens, or at some point, at the time of the merge, I have conflicts.
[00:16:45] So, uh, which will of course have to be managed, etc. Something that rarely happens when doing trunk-based.
[00:16:55] Uh, so there you go. I was saying Trunk Based Development is a reaction to Branch Based Development.
[00:17:06] And, uh, there's a question that arises, because if I'm in Trunk-based, well, how do I deliver my feature B when I haven't finished it? So there I release the purple square, in fact my feature B is not complete, so it's not necessarily deployable as is. And that's how we often associate feature flipping with trunk-based development.
[00:17:28] at least, because the idea is to deliver branch, well, feature B in off mode, until it's finished. Finally, the Trunk-based development, what we're going to do is we're going to deliver, well, activate only once our feature.
[00:17:51] So it will be deactivated, deactivated, deactivated until the moment when we are ready to deliver it, finally, so that it is usable, in any case, and there we activate it all the time. Except, let's remember. You'll keep the question for the end?
[00:18:08] Uh, let's remember what we said, that normally feature flipping is for multiple activation. So in fact, there, we are not really using feature flipping as it was originally designed. And, uh, those who use Trunk-based with feature flipping, well, in fact, they are doing, or they are doing disguised branch-based. Because it's the same thing.
[00:18:39] Uh, for partial delivery, is it precisely one of the cases that pushes you to do it today? To use feature flipping? Who, who uses, well, in any case, uses feature flipping for partial delivery of features? Yeah, a few. Okay. The goal of partial delivery is that behind it, there's a need to reassure. To reassure customers, to reassure management, to reassure, well, to reassure ourselves. To say that we are developing something. We are not just in a tunnel effect mode where we develop for one month, two months to finally deliver something.
[00:19:25] And above all, it helps to reduce the lifecycle of branches. So the idea is, I try not to keep an active branch for two months because the feature isn't finished. for partial feature deliveries. Yes, a few. Okay.
[00:18:59] The goal of partial delivery is that, behind it, there's a need to reassure, to reassure clients, to reassure management, to reassure, well, to reassure ourselves. To say that we are developing something. We're not just in a tunnel vision mode where we develop for one month, two months, to finally deliver something. And above all, it helps reduce the life cycle of branches. So the idea is I try, I don't keep an active branch for two months, because the feature is not finished.
[00:19:37] And so the question that arises is when we are in a sprint, for example. So we want to deliver, we have features, especially this one, which is over two sprints. I ask myself the question, is this batch of US not deliverable as is? And often the answer is we wait for the end of the feature to deliver the feature entirely.
[00:20:05] And there, we come back to characteristics or criteria that you know, INVEST. I'm not going to list them because I consider that you who doesn't know, by the way? Well, there it is, I suspected it. Nobody.
[00:20:21] But what mainly interests me in these criteria is the independent and valuable part. In fact, we forget that a US, when we write it, it must be valuable for the users. If it's not, it's because the split isn't necessarily well done. At least, maybe we can split it differently. And by the way, there is uh Richard Lorenz and Peter Green who created a kind of a of graph, let's say, of the different types of splits that we can apply. I don't know if you've already seen it, who has already seen this graph? Cool. The idea is really to say, I can split my US differently and I try to see which case I am in. To better split the feature. And if you consider that this type of split is a bit complicated and it's complicated for and for the teams, well, for the PO or the PO and for the Dev team. There's another simpler technique called the hamburger technique.
[00:21:32] which, well, which consists of saying, well, there's the top bun, which is the starting point, so the main goal. Uh the meat or the steak if we're in a sandwich, in a vegetarian burger, let's say. So it's the core functionality. And then all the details of a plan and so on, those are the ingredients we're going to add, the, how do you say? the salad, the cheese, etc. And then at the end, it's the endpoint for the bottom bun.
[00:22:07] And there, if we respect both the INVEST principle and split our features correctly, everything we deliver in a day or two will be deliverable as is. And so we don't need feature flipping in that case.
[00:22:23] Another case is activation based on context.
[00:22:28] Have you ever used it, have you ever Yes, two, three. Yes, a few. What is context-based activation? It's, for example, I want to activate during the Christmas period a feature. I want to activate it for France and Spain only, compared to the rest of the countries. Uh I want to activate this feature for the development environment but not for other environments. Uh I want to activate uh I take the case of A/B testing for a certain number, a sample of users. And there, the question that arises is, do we need to activate these features manually?
[00:23:11] Are these not ultimately dynamic business criteria? Yes. When I see that, I tell myself it's business. You don't need a switch to turn off or turn on the light. And in fact, in this case, we are in a case of a kind of, if we represent it as an activity diagram, we have treatments, we have a condition that corresponds, well, that tells us, in fact, we're going to use a treatment that corresponds to the which satisfies the conditions or else the other case. And in that case, for developers, at least. We can simply replace the feature toggles with the strategy design pattern, in particular. And uh we're going to say, well, we're simply going to create, we have an implementation of our, well, our initial processing, which will depend on an interface. And the interface will be implemented by two implementations, the case that corresponds to the condition, well, that corresponds, that satisfies the condition, and the other case that does not satisfy the condition. That's for the simple case. But we can also have more complex cases. Like campaign management. I've already seen feature flippers, well, feature flippers yes, to activate functionalities related to the sales period. or in relation to the Christmas period or even for payment if I have several types of payment, uh or I want to combine several types of payment. Like, I pay one part with gift cards and over several times, well, we had feature flippers for that. But actually, that's also more of a business case. And so it's not necessarily manual feature flippers that will manage them. There's a quote from Cyril Mercer who said if it's too important, well, if it's a feature anyway, it's a feature and don't use flaps for that.
[00:25:14] So uh depending on the context, if it's uh if it's when we are in activation mode based on context. If it's a new feature, it's probably, well, you have to ask yourself the question, isn't it a kind of subdomain in the DDD sense of the term, domain-driven design? Are we not in the process of, I'm talking about payment, it's often perhaps a separate subdomain? Can't I use, can't I replace the feature flipping I'm going to do with a pattern, a Gang of Four design pattern? and so on, like strategy, decorator or other. And there again, consequently, we don't need feature flippers.
[00:25:57] I'll now take the other case, the two versions in parallel. You're going to hate me, I'm destroying all the
[00:26:07] Have you ever had this case?
[00:26:11] Yes. Not much. Okay. Once again, we are in a context of what we call deal with legacy. It's that we have a legacy that we are potentially refactoring or retransforming. And we can have several ways, either a partial rewrite, a perhaps complete rewrite, a partial extraction of our code to put it elsewhere. In any case, all that, there are plenty of techniques, precisely, well, I said Aroa is a training center, so I'm taking the opportunity to advertise, we have a signature training called Pragmatique Archie. Uh where we present all the techniques to manage the legacy and how to get out of it when we have a big legacy that we want to refactor.
[00:27:00] And one or two techniques that we present are the Strangler Application Pattern and what we call the branch by abstraction technique. So uh the Strangler Application Pattern or uh what we also call it comes from the image of Strangler Figs which are strangler fig trees, I don't know if you know. These are plants that, uh, how do you say, that grow around a tall tree and strangle it, in fact, they take all the energy from the tree until it dies.
[00:27:41] It's ugly, but we can use it in our daily dev life. And the idea is to create precisely the new application and we will not manage the legacy and we will consider that all the refactorings that we will do little by little, in fact, we will do them directly in the new code. And that way, the legacy shrinks, and the more we migrate a feature, the more we remove it directly, we don't leave the choice of feature flipper clearly. And so the legacy shrinks, shrinks until it disappears. That's kind of the idea.
[00:28:18] On the other hand, the second technique I was talking about is branch by abstraction, so another technique that allows us to make large-scale modifications. Uh Martin Fowler talked about it, and how does it work? Uh in fact, we have, for example, clients who use the legacy that we want to replace. So we're going to create a kind of abstraction that we're going to route to a client for testing, and the abstraction is implemented by our legacy. And if all goes well, we reroute all clients to this abstraction. And then, uh we're going to create the new version that implements this same abstraction, which we'll test on a client, and if all goes well, hop, we'll switch everyone over to it. And that way, we no longer have legacy. And we do that little by little on the features and it's a bit the same effect as the Strangler App, which is that little by little the legacy disappears.
[00:29:21] So in fact, for the two versions in parallel, we will indeed have the two shows of how I deal with legacy via patterns and techniques like the Strangler App pattern and the branch by abstraction.
[00:29:40] And once again, so, you see it coming, I don't need a feature flipper.
[00:29:52] Another case, external dependencies.
[00:29:57] Do you need it, have you used it? Have you ever had the case? I imagine yes. Yes.
[00:30:06] We often need an external dependency. What is it? So it's a service that we need but that is not within our perimeter. So it's a payment service, for example, or an API that we call from a provider or, well, there can be many, many cases. Uh there's also a news publishing service, for example. And there, what happens? We often tend to want to apply the feature flip. for or because of a lack of confidence in the availability, especially of that service. So we don't really trust this service, so I'm going to put a flipper to verify, well, if I have a bug in production, I'll deactivate it directly. But here, I rather suggest another technique.
[00:30:56] that's called the circuit breaker. It's like the circuit breaker at home, when there's a short circuit, hop, it trips by itself.
[00:31:06] You don't need to go into the electrical box to cut off all the electricity in the house. We agree? Well, it's the same here. And in fact, what is the circuit breaker? It's both a health check, so it verifies that the service is always available, and if there's the slightest problem, if my health check is not good, then I, hop, I deactivate it automatically. So it's a kind of combination between the health check and the feature flipping. Automatic, again, not manual. And there, indeed, if we manage to implement that, we are calm. We manage automatically, there's no need for human supervision, let's say, regarding that point.
[00:31:53] Now, there's the case of the client's explicit request. What are we going to do for him? Have you ever had this case? Who has, well, who found themselves forced to use feature flipping? Oh, not many, that's good.
[00:32:12] So in that case, indeed, the person, or rather he or she, potentially hasn't understood the use or usage of feature flippers. And now I'm going to do a little advertising, don't hesitate to present this presentation to him.
[00:32:29] Uh there you go, so to summarize, in fact, feature flipping for me is a question. well it's a convenience solution rather, a convenience to say ah, if I need it, at least it's my insurance side to tell me I'll deactivate it when there's a problem. A convenience solution because I don't need to actually deal with finding another solution. But uh you have to tell yourself that this convenience solution is useful in the short term, but you have to be aware that in the long term, it won't necessarily be profitable because there are all these drawbacks that we saw at the beginning. It's that the code becomes more and more difficult to maintain. Uh the additional cost of analysis that we will have to manage to verify that everything, well, if we add a flipper, that it still works well with the existing one, and so that means longer non-regression tests, longer non-rule tests, or at least sometimes even non-rule test campaigns. And above all, the worst is the turnover in the teams because if the developers are not happy and satisfied with what is happening, with the technical environment, well, they won't stay.
[00:33:52] And so as we've seen, there are many alternatives precisely for this, and the solutions are multiple, whether it's in relation to a better split. design patterns, they're not there to look pretty, we can use them.
[00:34:09] Uh domain driven design, same. Uh if we correctly decompose the domains and subdomains, we can do better by identifying the features in which domain it is and there will be no more need. and then patterns to manage the legacy, the Strangler app or the branch by abstraction. And in the ultimate case, a circuit breaker, that will do the trick very well instead of a manual activation or deactivation of feature flipping. There, if you want to continue to participate in the survey, do not hesitate, it will make me even happier to have more opinions than those we have had so far. And uh I thank you.
[00:35:01] I don't know if there are any questions. Earlier, yes.
[00:35:07] Yes, there. Excuse me.
[00:35:20] 1 2 3 1. In fact, my question earlier was about trunk-based development, where I was wondering, to avoid having the habit of working on this type of Git flow, I was wondering where we do code reviews, unlike the MR requests we might have with branch-based development?
[00:35:40] Well, often trunk-based development also comes with pair or mob programming. When we do it, and so we no longer need code review, we do it naturally during development.
[00:35:53] Very good, thank you.
[00:35:57] There's one there.
[00:36:02] So thank you very much for this talk, it was super interesting.
[00:36:07] I'm right in the middle of the subject because we're in the process of looking into implementing trunk base, of course everyone is talking about feature flags, it's a big debate and sometimes we use it well, sometimes not so well, there are cases where I thought oh yes, we should have done it differently. So it gives me new ideas, so that's super cool.
[00:36:22] However, I also have the impression that people are attached to feature flags because today there are SAS that provide feature flags with even non-tech people who are autonomous to define their flags, define the conditions of the flags, activate them, deactivate them, and there are also teams with product people etc. who I also have the impression are attached to this, to the fact of not having to go through the development team to change a condition of an existing flag, saying no, no, it's no longer 2% of users, it's 5% or I change the country or etc. etc. I don't know if you also had feedback on this, on the fact that many feature flag systems actually also give the autonomy to create and customize flags to teams that are not part of, let's say, well, that are not technical, in fact, who then have autonomy over this. Thank you.
[00:37:07] Indeed, often feature flags are, well, activation and deactivation are done directly by the POs. And that too, well, in any case, what I often advise is to say instead of arriving at the moment when why do we need to activate and deactivate, it's because there's also a lack of trust.
[00:37:28] That's right.
[00:37:28] That's it. And so instead of getting to that point and saying I need this assurance to guarantee that everything works, let's work upstream on the split of US, the prioritization and exactly why things are the way they are, the product vision. And there, immediately, we change the course, there will no longer be any need for feature flipping.
[00:37:52] Yes, that's true, lack of trust is a real thing, it's a real issue. Thank you.
[00:37:57] There's one there.
[00:38:01] Thank you. Uh hello and thank you for the presentation. Uh I have a question, when you qualify a feature flag or flipping, uh does it only concern the prod environment or uh even before, in fact, the dev, staging, etc. environments? Because often we are led to create And do the blocked US represent feature flipping for you?
[00:38:47] I hear two questions in one. So, are feature flippers only for the production environment? No, because we can very well have feature flippers for dev environments, and there's even the case of activation by context, we can very well have a feature that is activated in the development environment and not in the production environment for example, because precisely it's a case of a bottleneck from an external service that we don't want, that doesn't offer a dev environment in particular. So there's that case, indeed, but there, similarly, if we use the strategy pattern, we can say that in the production environment, we use the production implementation, and in the dev environment, we use the environment, well, the part, well, the implementation that corresponds to dev and immediately, it's handled by the IoC side, well, the inversion of control. And so in the production environment, I retrieve the implementation which is the bottleneck, and in the production environment, I retrieve the actual instance. That can also be managed by patterns, that's my point, and so we don't need flippers. of an external service that we don't want, that doesn't offer a dev environment, notably. So there's that case, indeed. But there, again, if we use the strategy pattern, we can say that in the prod environment, we use the prod implementation, and in the dev environment, we use the, well, the part, the implementation that corresponds to dev. And immediately, it's on the IOC side, well, the inversion of control, that it's managed.
[00:39:41] And so in the prod environment, I retrieve the implementation that is the stub. And in the prod environment, I retrieve the actual instance. It can also be managed by patterns. That's my point. And so we don't need flippers.
[00:39:59] Just behind.
[00:40:01] I wanted to, first of all, thanks for the presentation. I wanted to bounce back on that question. There's a whole story about cost, especially in development, in a development environment, we don't want to bother making solutions that are more time-consuming, knowing that we know very well that we're going to delete them just before they leave, well. Sometimes, well, that was in prod dev, but things we do in dev only. So there's a cost story. In fact, we didn't, well, you didn't talk at all about the cost story on putting certain methods in place. Knowing that there are certain clients who clearly told me that it wasn't serious, it was cardboard. What, what is the minimal solution we can put in place?
[00:40:43] Just a question before I answer, to know if I understood correctly. The question of cost, is it relative to what? To the use of flippers or to the implementation, like I create, well, I use a pattern?
[00:40:57] It's the use of flippers. Sometimes, I feel like we don't have a choice. And at what point, in fact, is it worth spending money to put in place, let's say, we put in design patterns, we really think about properly breaking down user stories and so on, because it takes time, for perhaps something that is disposable.
[00:41:19] Hmm.
[00:41:22] In that case, well, first of all, if it's disposable, won't it be a POC? I mean, in that sense, if it's disposable.
[00:41:32] It would be in an ideal world.
[00:41:36] There, it's the same, it's, uh, it's in our mind, we think about what we're going to do. Is it a POC? In that case, wouldn't it deserve, then, to be entirely independent of the application we're working on, to deploy it elsewhere? Not necessarily in a dev or UAT environment to specifically test that POC. That's the first solution. And it doesn't cost much, well, it doesn't cost much, it costs the cost of the environment we want to create separately. That's what it will cost, potentially, if we do that. Then. The implementation of patterns, it doesn't cost that much compared to the libraries or the cost, the consequences, in any case, of the flippers that we're going to use. That's what we need to keep in mind. Today, indeed, we have the impression of doing a flag or a flip, a flipper, it's not expensive. But behind, potentially, is the management of these flippers something we've done in-house? So we'll have to create all possible cases. Are we going to use a library that manages the flippers?
[00:42:38] Well, there we're adding a dependency to our project that's potentially not useful. And in parallel to that, making a kind of strategy pattern just like that, with just one interface and two implementations, I don't think it costs very much. So it's a choice, but, well, I'm intimately convinced that feature flipping is more of an easy solution. We don't want to think, we don't want to bother, and so we're going to use the simplest solution. At its expense, but with serious consequences for T+1.
[00:43:14] Thank you very much.
[00:43:16] You're welcome. There's a question in the middle, just behind.
[00:43:24] Uh, thank you very much, Doria. Uh, I wanted to know, so you've given us a lot of cases where we shouldn't use feature flipping.
[00:43:33] In any case, uh, you also said it was a smell. Do you see, even if it's just one case, or a few cases, where uh it could be useful?
[00:43:47] The only case I see is that one. And not just feature flipping alone. It's, uh, we try to automate. In fact, my point is both the use of feature flipping libraries or feature flipping frameworks, but also the manual side that bothers me. That means we react to a bug, or we react, we arrive too late, in fact. It's that the damage is done, so to speak. Whereas if we do a health check, for example, or uh, minimalist tests to verify that the whole environment is uh, okay, and have automatic feature flipping, that suits me. It's just the manual side that bothers me, that deserves it. Thank you. I don't know if I answered your question, then.
[00:44:38] Uh, yes, uh, precise if I can continue, in fact, I use it a lot with TBD. However, to your point, that is, there aren't any everywhere. There are very few where we really need it. Uh, I find that in certain cases for TBD, for when we can't properly cut or when the client doesn't want their feature right away before other parts of the feature are finished, etc. Uh, sometimes I do see an advantage. So it was to know if you also had a similar experience or not.
[00:45:09] So, uh, I haven't seen it yet, but that doesn't mean it doesn't exist, maybe it exists, but in any case, I haven't yet seen a use case that would really deserve a feature flipping.
[00:45:25] Thank you very much.
[00:45:33] Well then.
[00:45:37] Thank you. One of the cases you mentioned was the AB test part, in particular. How do you see it without feature flipping, or is it an abuse of naming to talk about AB test with feature flipping?
[00:45:54] Is it, uh, I try to rephrase your question, is feature flipping an abuse for AB testing, is that it?
[00:46:01] Yes.
[00:46:04] In fact, when AB testing is done in-house, uh, often we, well, I don't know in which, have you used it before?
[00:46:13] Already the AB testing part. Implemented, in fact, on front-end elements, both for conversion, for example, in e-commerce, and then for testing user interfaces.
[00:46:23] And we wanted to, we wanted to deploy it. And just to finish the question, especially on the UX part.
[00:46:29] We told ourselves that we would rather be in a Canary approach, meaning to deliver progressively and not all customers at the same time. So it's not AB testing, but rather Canary that we put in place. Okay.
[00:46:43] In fact, the question that arises is, is AB, well, AB testing, what is it? It's uh, I take a sample of users and I redirect them to a version, uh, and I keep all the others, well, if I have two versions, after if I have several, I sample. And the question that arises is, is the sampling I do, is it, well, what is the rule to identify that sampling?
[00:47:11] Is it the number? Is it a particular user profile? And in fact, that's the question: what is my criterion? If it's a business criterion, well, in that case, it's not feature flipping. It's rather, precisely, business criteria, and uh, that means I have a choice, uh, well, if my user corresponds to these criteria, I redirect them there.
[00:47:35] We are not necessarily in feature flipping.
[00:47:40] In other cases, maybe if it's a kind, well, it's the number, I take the first 10, the last 10. Well, it's the same, in a way, it's uh, I have my users and I redirect them. In fact, if you, if you want to implement it in a way that uses feature flipping, what does that mean? It means that it's not one flipper that you're going to use, it's several.
[00:48:05] So we agree, that is to say that AB testing is another subject. It's, we can't, it's not feature flipping.
[00:48:11] Yes, clearly yes.
[00:48:19] Do you want to go to the market of the day? Thank you.
[00:48:26] Thank you. Uh, my question was to be sure if we had to synthesize in one sentence what you say is that we must avoid manually activating, but that it is done automatically in the end. If I understand correctly, is that the difference you make between the feature flag which is manual and all the rest, everything you present, is finally that it has to be done automatically in one way or another. Is that it?
[00:48:49] More than that. What I really invite you to say is that if you ever need feature flipping, ask yourself the question, what is my use case already? If I have, I am in one of the use cases that I have put, I take the slide, hop, that one. Basically, if I am in one of the use cases, really the, all the use cases apart from the external dependency, well, in fact, I don't really need feature flipping. The only case where I feel there is a need for feature flipping, but automatic, is the external dependency. And there I do circuit breaker rather than a classic manual feature flipping. That's my point.
[00:49:36] Okay, because in the end, in all cases, there will always be a condition somewhere. It's, since there's a chosen path, whether it's chosen statically at compilation, a config file or whatever. So the ifs always exist in the end, we agree.
[00:49:53] Yes.
[00:49:55] Yes, yes. So, what, what I'm talking about there is feature flipping using feature flipping tools and libraries. A business condition is in some way a switch. So it's a natural flipper, but it's business, it's not technical, it's a config in the database that I manually set. That's the difference.
[00:50:17] Okay, that's good. Thank you.
[00:50:21] Other questions?
[00:50:25] Bravo. Thank you very much.

Transcript (Translated)