We've talked about the use of feature flags in the context of your delivery pipeline. I'm here with Adam Zimman who is the Vice President of product and platform at LaunchDarkly, and LaunchDarkly operates an infrastructure to help companies manage their feature flags and they've learned a lot about what works and how companies go about doing this. Adam thanks for joining us. My pleasure Alex thanks for having me. Can you tell us a little bit about your role today at LaunchDarkly?. Absolutely. So, as VP of product and platform, I'm here to make sure that we provide a robust platform that people can use to be able to manage their features. We think of it as a feature management platform that does feature flagging plus. So, it is all of the access controls, it's all of the audit logging, everything that you would want to build to have robust management of the delivery of your features. And can you talk a little bit about how you got interested in this in the first place? Absolutely. So, I've been doing enterprise software for quite a long time. I was at VMware for a little over ten years. After that I went to GitHub and saw how people were doing modern application development and it started to get really intrigued by the idea of how people were able to move much faster. So the contexts that move fast and break things, but with the sub-context of making sure that things, when they broke, you were prepared for it and you were able to recover quickly, and a big part of that was actually the use of feature flags by GitHub. Got it. And then can you talk about the evolution of LaunchDarkly itself, I mean what were the observations and learning that led it to where it is now? Absolutely. So, Edith and John the two founders of the company started the company about four years ago and they realized that at every software company they'd ever been asked over the past 20 plus years, they were encountering the need to build this type of system whether it was even in the days of packaged software having some way to be able to encapsulate, configuration files for hidden code paths or in the days of actual internet delivery are cloud-based services, they were needing to be able to have this sit where they could separate the notion of deployment of code from the release of features. And they wanted to be able to say, "Hey look, we can build something that is usable not only by everyone." So instead of having a custom builder homegrown built by an individual company, but also it takes care of providing all the feature functionality that was always, we'll get to that at some point or later on in the road map and making sure that it was kind of being treated as a first class application and first class platform for delivery. And zooming out a little bit, what have you guys learned about how feature flags help the overall product program in general? Absolutely. So, we really look at feature flags as being the thing that makes continuous delivery successful. It's one of those things where when you're starting to go down the path of continuous delivery where you want to really move fast, the biggest challenge for most organizations in moving that fast is risk. Whether or not their deployment is going to actually have catastrophic negative impact on their customer base, and with feature flags you can truly eliminate that risk because you're suddenly able to have a control point like I said before of separating the deployment of your code from the release of those features. And by having that control point in the code itself it gives you the opportunity to worst-case scenario, you ship something, you expose it to a customer and the customer doesn't like it, you need to turn it off, instantaneously you hit a kill switch, it's off. You don't have to worry about a redeploy which can take, if you're really good, few minutes, if you're really kind of struggling that can take half a day to get a full deployment an application. And when customers are moving and evolving along this path of getting to these more progressive deliveries, who actually does this stuff? Who manages this process of turning these feature flags on and off for different audiences? Yeah. When you're starting to move past this notion of continuous delivery to progressive delivery, a lot of that starts to introduce the idea that you don't just want to have a feature on or off, you actually want to be able to progressively increase the exposure to these features into various cohorts. This could be starting with your engineers where you want to have the control for an engineer to turning things on or off for themselves in their own development environment, or your operations team, you want to give them that the tools to be able to say that same control point and turn it on and off in staging versus production. But the interesting thing about this is that once you create that control point and provide delegation around it, you can start to expose that control point to even more of the business owners right? So, your product managers can control who gets to have access to a data functionality. Your customer success or sales individuals can control the extension of a trial period or the ability to enhance a trial with other features that may only otherwise be available in higher-order plans. It really opens up the opportunity to be able to enable anybody that has a stake in that notion of the release and who gets to see a feature to have control over it. And we have a learner here that's hearing all this and they're thinking, "Oh, this a good idea. Should get started with these feature flags." But how do you recommend that they get started? Best part about feature flags is that you can get started with the next thing you're working on. So, this was the whole concept that dying contradict GitHub. Was that the very first thing that an engineer would do is they would basically create a empty shell of a feature flag where you would create an if statement that allowed for the feature flag to be named and catalog, and then you would basically checking in with no actual code path underneath it. So, say, if all things being equal just do what you normally do. Else, if you have some variation that's explicit, you can use this new code path and to begin with there's nothing there, but then over time you're able to add that new code that's underneath without having to expose it, and this gave a lot of speed to your development life cycle as well as it completely eliminated the risk because you had this kind of known good cap that you already had in place that you didn't need to worry about. Some great perspective from the trenches Adam, thank you so much for joining us. My pleasure Alex. Thanks for having me.
