Ep. #24, Beyond Code with Heidi Waterhouse of LaunchDarkly

Heidi Waterhouse: Before anybody starts to do a feature flag, I need them to understand what their software does in the first place.

Charity Majors: Oh, that's a tall order.

Heidi: I know, but I feel like we would build better software if we knew how it was going to end up, just a crazy thought I had.

Liz Fong-Jones: Some kind of similar, I guess, to this idea from Chaos engineering, that, if you don't understand what the question is that you're asking, if you don't understand your hypothesis and you can't possibly run an experiment.

Heidi: Yeah! I think it has been easy for developers to follow orders and just following orders is always the worst plan.

Charity: I agree, that is the ideal! But how many of your users actually meet that bar before they get started?

Heidi: I don't know that the individual developers do but, we find that when people are incorporating feature flags, they've gotten far enough down the path that they're like, wow!

I wish that some part of this didn't work all the time or did work part of the time and once they've gotten that far, then they can have a conversation about, you don't need to know why this is wrapped in a feature flag, you just need to know that somebody cares.

Charity: And it sounded like you were saying that people come to you because they've run into a wall.

Like, they know that they want to deploy their code, but not to everyone at once. They want to have more control over it, or they've been burned.

Like, they've accidentally blasted it to everyone and I can see this, like, this is a pain that pretty much everyone who's ever deployed software has had at one point, right?

Heidi: Yeah. I think that, everybody has pushed to production when they shouldn't. I do.

Liz: I have a friend who works at Squarespace, who has said that she had her heart rate go up like, you know, twice as fast because someone sent him an in Slack, " Oops! Did I run that against production by mistake?" Answer is no, as it turned out, but--

Heidi: So, I'm teaching my kids to drive right now and I'm thinking a lot about how this is one of those analogies that's just going to haunt my conference talks forever.

The way you teach people things is not to give them this like academic setting. Like, they took driver's ed on Zoom.

Charity: You create a craving in them.

Heidi: Yeah! Like, to teach a man to build a ship, you must instill a yearning for the sea but, also it doesn't matter how much Zoom, driver's ed you had, you have to get behind the wheel.

You don't have to get behind the wheel on the freeway, you can get behind the wheel at like midnight, in a dark suburb, in a parking lot.

Charity: Controlled circumstances.

Heidi: Right. And then, as you gain confidence, you are going to move to bigger environments, you're going to move to more complexity, it's going to give you more capacity to do things like, you can't go buy milk if all you can do is drive in a parking lot.

Charity: Yeah.

Heidi: You can buy milk if you can drive like back roads but you can't really go interstate if you can't do freeway speeds. So you're just going to keep ramping up.

Charity: Well, I grew up in Idaho where like, there were like 1300 people for the, yeah but, I take your point in the civilization, yes, absolutely!

Yeah, no, I like this and I feel like this is kind of, we talk a lot about the battle days when ops was like, "stay out of production and this is my area!"

You know, and devs are like, "but we want to play," you know?

And like people ask me surprisingly often, what do you mean by guard rails?

What does it mean to build guard rails for your developers so that they're, you know, and I think of production kind of like a playground, right?

And it's a playground. You don't want your kid to die going down the slide.

Heidi: Right. We've taken all the metal stuff out, like mostly, you're not going to to rip anything open.

Charity: Yeah. They can get a thing done but like, the swing set is not literally like 30 feet off the ground.

Like, you don't want it to be that easy for people to die. There was risk, right?

But, like, making it sized appropriately, like feature flags is the first thing that I always jumped to when it, because it decreases the scope, it gives you control over the scope.

Who do you want to see this? When?

And you can just flip it without even having to go through the whole deploy process.

Heidi: Right. And I think that's a really interesting thing.

Like, you've been talking a ton about how important it is to be able to deploy, in living memory of when you wrote the thing and then see the results.

And, that feedback loop is something that we've been, I don't want to say idolatry in CICD, but kind of--

Charity: It's one of the those like the, what do they call it?

Cornerstone species or whatever, like the, the foundation of an ecosystem.

If you can get that right, so many things are set up to go right by default, without you having to think or try really hard.

And if you get that wrong, so many things are set up to go very poorly.

Liz: Right. So to circle things back around to the question that we originally asked, it sounds like feature flags and the ability to deploy small changes safely, that actually isn't the, you must be this tall a ride, for many other things.

Heidi: Yes.

Liz: There's really not, not that much of a, you must be this tall a ride for feature flags but it in turn enables you to do so many more things

Charity: By the way, this seems like a good time for you to introduce yourself.

Heidi: My name is Heidi Waterhouse. I am the principal developer advocate at LaunchDarkly.

I've been there three years, I just hit my anniversary, and I have spent that entire time going around the world, telling people that they could be less scared if they just used this tool.

And, I feel like we're finally getting somewhere where we can combine that with chaos, we can combine that with observability and say, what if, development and deployment were not the scariest thing you did with your day?

Charity: Yeah and it's like, there's this craving on the parts of many people to hear that all they need to do is buy one tool, buy a tool, do a thing, you know, and a lot of vendors play into this too because they'll be like, "well, my tool is the best tool, "buy my tool," always bullshit!

But there's this whole ecosystem and it's kind of like, once you dip your toe into one corner of the pool, you start to see why you need other pieces other parts of it, right?

Like, they enhance each other, they play together nicely, they amplify each other and they give you super powers.

Heidi: And I think the interesting thing is like, we just did a survey and LaunchDarkly has about 200 employees and about 240 applications in our Okta, which made me want to lie on the floor and die honestly I can't, I can't handle this, but, not everybody sees every application.

Like, I don't need Salesforce, I don't need Zendesk, those are not my problems, so, those can be partitioned off from me.

But, I think all of these things that we are doing tools for, are not new, like feature flags are not new, It's just that people had--

Liz: Its known that they have been done over and over and people have gotten these shitty re-implantations of them, right?

Heidi: But it turns out that we have finally hit a cost tipping point for tools that makes it affordable to not roll your own, that you can buy this and it's better to spend your time on other stuff.

Charity: Well, some of the stuff that you guys have done, it's been, you've done some really interesting novel stuff on the front end and correct me if I'm wrong, I could be completely out of date here but my understanding of your business model was, you're basically selling to like, marketing teams and not developers as much, you know, the less technical people to be able to flip things on and off.

Heidi: So, it depends much like the myth about the elephant and you know, which part of it you grab. It depends who you ask.

If you ask our front end sales team, what is exciting?

They're like, what if product managers could do this without having to bug dev to turn something on for them?

If you ask the dev team, what they say is what if product managers could do this without bugging us?

And, what if I had the power to do my own testing?

What if I could see my stuff in production without going through this entire approval process?

If you ask me, I think that like the longterm payout now that we've added workflows, is workflow management is almost middleware.

Charity: Say more about that.

Heidi: So, and this is like heterodox even in the company just to be clear.

But I think what we are actually providing is an ability for people to execute business logic without knowing code.

And I don't want to say codeless, there's a lot of code.

Charity: Sure.

Heidi: But--

The people writing the code, don't always have their finger on the pulse of what the user needs.

Charity: And like, writing code is hard. It takes a lot of cognitive and emotional energy.

And, just as a principal, I live my life by is try to do the laziest thing that you can, right?

It's democratizing, it makes it so that it's, you know, if it's not like this, you have to be the priest in our cult in order to like flip these flags, right?

It means, it's more participatory, it means that, you know.

I've often said that, tools build silos, the border of your tool is where the silo edge sits. If you don't share the same view of reality, if you don't share the same interface, if you don't share the same tool set, then you're living in different worlds.

And what I love about, I think that software engineers, I think that we're getting a little less naughty about this stuff, when is there, there are no like new vims that are being written, right?

Like we're, we're like, actually we are human beings, we are prone to human bias, just like all the other human creatures around us, right?

And it turns out when you make tools that work well for non-engineers, they're really great for engineers too.

Heidi: Yeah. That's, that's kind of what I'm thinking.

Liz: Yeah, it's a super interesting thing, right?

Like, we see our sales engineers and our account executives turning on and off flags for customers, right?

And it's, it's amazing to see them just, you know, reach in and do it and it's just like, you know what?

Okay, they don't have to know how to write a single line of code to do this. This is super exciting!

Charity: So many people have been, you know, raised with this idea of coding is like, it is literally magic.

Like, if you're not a quote, unquote coder, you, you're not in the club, you don't understand, It must be so far outside your comprehension.

Liz: There's almost this weird paradigm with like, you know, not just the code, but then the config for the code, right?

Like, you know, there used to be software engineers who were definitely afraid of touching yaml files, right? And for good reason.

Charity: I know so many people who, don't write a single line of code, like our marketing person Deirdre and yet can talk about it so much more intelligently and intelligibly.

Like, she understands what she's saying. She can come up with great new insights, she doesn't need to be able to write code, to understand technology.

And there are plenty of people out there who do write code, who can't do that.

I feel like these skill sets are not, they're not overlapping the way we treat them at all understanding and doing are not the same thing.

Heidi: Yeah and like I'm a non-coding devrel, which is sort of a weird place to be.

Charity: I've always been intrigued by that, can we detour a little and talk about your journey?

Heidi: Sure. I spent 20 years doing technical writing for a succession of companies.

About 18 months in, I had learned everything I was interested in and about the company, fixed their documentation and I would ride off into the sunset.

I eventually made a business doing that, where I'm just like, okay, startups, you have fucked up and you have not done documentation and now you're like two years down the line and it needs to happen and you don't know where to start.

So I'm going to to come in, fix it all for you and leave it so that you can hire somebody less expensive to maintain it.

That means that I knew the product and the theory

Charity: And you can't fake it.

Heidi: And you can't fake it. So like, I worked on Microsoft BitLocker.

It was like one of the projects that was really revolutionary for how I thought about these things.

And, I knew everything from, I sat in meetings where we had an argument about the switch that had to flip, like, it was actually a physical hardware flag at boot time to enable the TPM chip to basically report that it was feeling okay.

Charity: You didn't understand a word of what you were talking about, I can tell.

Heidi: Yeah, exactly. All the way up to I'm watching end user tests of windows 2008, and seeing how tragically that whole security check was going to fail.

Charity: Why didn't you decide? Cause it's the easy answer, is to go, well, this is the path that is, people look up to, it has the prestige and the money. Like what, why didn't you?

Heidi: I find it boring. I find the problems in socio human technical systems, much more interesting than I find figuring out where the hell I put that semi-colon and could I learn it?

Probably, will I learn it someday? Maybe, I was looking at like, maybe I'll do some glitch apps because I have some things I want to express.

Charity: Tech for me has always been about solving a problem.

Like, I cannot motivate myself to do something, unless I believe it is the most important problem, the number one, the thing that is blocking us, right?

I can motivate myself to do literally anything, if it's that, if it's anything else, I can't do it.

Heidi: Yeah, I struggle with that because I'm like, okay, but I could solve this problem for the longterm, or the thing you're asking me about is a short term fix and I don't want to do it cause it's dumb.

Charity: Yeah. I struggle with it because, I feel like I would love to be someone who does computers for fun.

I would love to have hobby apps, I would love to be someone who can just sit there and learn a language and fuck around.

And I've tried and I just don't know how to get my brain to fire on those cylinders.

It feels to me, like it's a pure form of motivation then, well, rage, honestly, I run on rage, let's be honest.

I feel like I burn it as a fairly clean fuel but it's still rage, it feels like, you know, being motivated by the joy of the technology, I would enjoy that feeling if I could feel it.

Liz: Hmm, so interesting because one of the conferences, I'm a huge fan of, I'm not sure have you been to this conference before Heidi?

It's called !!Con (pronounced "Bang Bang Con"), it's about the joy and surprise of computing.

Heidi: I've attended it and I find it charming. I've never gotten a talk in, but someday.

Charity: You said it was the joy of programming Liz?

Liz: The surprising joy of programming.

Charity: Oh, I like that.

Heidi: All of my conference talks also run on rage, like every single one. The secret beginning of the talk is, I'm really pissed off about--

Charity: This is why we're friends.

Heidi: The talk that I'm currently gestating is about Lillian Gilbreth, who was an early motion studies expert.

Like she's the reason we understand "the kitchen triangle." And, I want to talk about developer ergonomics--

Charity: Oh, Oh! The mum from cheaper by the dozen!

Heidi: The mum from cheaper by the dozen.

Charity: Oh, yeah, - Right? Yeah, love those books. I read the biography of her by one of her kids too.

Heidi: Yeah. But like, let's talk about developer ergonomics from a really feminist point of view to say, work is not value in itself.

Work is value because it accomplishes something, like, there's no merit in walking across your kitchen 20 times or in using an IED that doesn't work for you.

Liz: There's so many people who don't get that, so, so many.

Charity: You know, okay. Devil's advocate though, I feel like is what we do, is it labor? Or is it creative output?

You know, is it labor that we do because you know, you get where there's a spectrum there.

And a lot of what makes us love our jobs and everything is yes, it's labor, but it's also, there's this creative aspect to it that is, you can't do as good of a job if you don't love it.

And I feel like there's a contradiction there where I have just learned to love the hate, I have often thought like systems are getting so complex, so complicated, so hard, so intricate that, you can't really just show up and clock in and clock out and do something by rote.

I feel like, you have to be pretty emotionally invested in it, to keep up and to master modern systems, which was not really true of the Lamp Stack.

There was a lot you could just like, you know, run this, run that, you know, automate a little bit and I feel like it is becoming more of an art form.

Heidi: So, a couple of years ago, I watched a talk by DHH called "Read me" and, this talk blew my doors off because he talked about conceptual compression, he also talked about picketing and being divorced from the product of your labor and how it causes ethical decline.

It was great! But he talked about conceptual compression.

That every time we come up with something to make our lives easier, we don't acknowledge that we're squishing other things down further in the stack and not necessarily understanding them, which is what we have to do to understand modern systems.

So I don't know that we need to like, be emotionally invested in modern systems, but I think we do need to acknowledge that the complexity has its own requirements and it's either a really solid foundation or the willingness to like burrow through it.

I have this interesting point of view partially because, you know, I live in Minnesota and unlike when I come to San Francisco, people go to their day jobs as programmers for like Target and Medtronic and then they go home and talk about other things.

Charity: Exactly! Like San Francisco, like the Bay area is still where most innovation is happening.

There's this hot bed of people who are really passionate about what they're doing and, people come here when they crave that and they seem to leave when they're done with it.

Heidi: Maybe, I don't know, like it's--

Liz: Kind of, that's true, I think its where the funding is, where the--

Charity: It's not universally true, but it is largely true and it is somewhat self-reinforcing.

Heidi: I think there's good P.R, I think there's probably--

Charity: So, I've spent the last three years traveling the world, giving talks over and over and over and over and I used to think it was a myth and I no longer do.

Heidi: Yeah. I also have this problem where I'm like, it's really easy to be self-reinforcing and the devOps dev tools startup landia, there are far more developers working for Target, than like any of our 10 favorite companies.

Charity: So, let's talk about the DORA metrics, you know, like 2018, 2019.

And I'm so depressed that like, there's going to be no more DORA reports, it's just--

Heidi: Uh, filled my Google.

Charity: Oh my God.

Heidi: Gosh, darn it!

Charity: But like you notice that like 2018 to 2019, like, the bottom 50% are like losing ground and the top 20% are like starting to reach escape velocity and, I don't have like their caliber of data yet, but it seems to be that, the tool set, the self-reinforcing tool set, if you don't, you get started with feature flags and you want observability and you might, you know, if you're standing still in computers, you're losing ground.

Heidi: Absolutely!

Liz: Where are you? There are some systems that aren't growing, right? That just need kind of care and feeding that--

Charity: We're absolutely speaking in generalities that are not a hundred percent true, but, I think by and large every system I've ever worked on, you're losing ground if you're not trying to stay ahead.

Heidi: Yes. I can certainly see that and I certainly see like, the devOps transformation of large, old companies is fascinating to watch and, I just finished reading "Project a product" which was great.

And it was like, why do these things keep failing? Why can't you get a devOps transformation to work in a, you know, billion dollar enterprise.

Charity: Yeah, 'cause it has nothing to do with being a better engineer or a worse engineer. Like, it has nothing to do with that whatsoever! What do you think it has to do with?

Heidi: Value-stream mapping. And now I sound like one of the, like analyst wankers

Charity: Sorry what was that?

Heidi: Value stream mapping.

Charity: Value stream mapping? I've never heard of this.

Heidi: What are you doing that makes the value you for the customer?

What are people paying you to do? And how do you trace that back through all the layers of your company.

Liz: And the gentleman who kind of introduced this to the software world, his name is Simon Wardley

Charity: Is this Wardley?

Liz: Yes. And he kind of introduces this idea of trying to figure out what is generic heavy lifting, right?

And what is your unique value, right? And trying to disentangle, right?

Like, you know, which pieces in that stack, in that chain are where, right?

And it's not necessarily true, the higher up or the lower down it is, the more heavy lifting or unique value it is.

It really, really depends. So, that's kind of the really cool thing that I love about value stream mapping too, is that like, it lets you kind of crystallize and visualize all of this stuff.

Charity: Hmm, interesting.

Heidi: It's super interesting and it's a new way to think about it because it says not, what are we making, but like, what value do other people derive from what we're making?

Liz: And Charity, you may have actually seen this, when we put together the observability new 30 model, right?

Like, we used a value map for that rather than, rather than--

Charity: I remember what you did and I also remember not fully getting it, like, it was not clear to me that the process was what led to the result, I guess, but I need to like understand this much more.

That was the first time I encountered it. And it clearly didn't really click with me.

Heidi: I think like you have to run into it a few times and Charity, your history has absolutely proven your point about if you're not running, you're falling behind.

I think that, a lot of the DORA report indicates that if you are not transforming, you're going to get eaten by people who are, that's not exactly the same thing.

You could be delivering good value without transforming and you're fine until you get disrupted.

Charity: Yeah, absolutely.

Heidi: Like, for example, like the New Jersey unemployment system was working fine, until there was a catastrophic load on it and then, everything broke because nobody predicted, tested that.

Liz: Hmm, so I think maybe that refutes my earlier hypothesis, that there were some systems that don't need to kind of advance in that, you know--

Charity: Well, they don't until they do.

Liz: Yeah, they don't until they do, okay, yep!

I'll concede, I was wrong earlier. You've changed my mind.

Heidi: But yeah, it's, it's super interesting to me though, like how long can you go?

Charity: I mean the New York times is still running on COBOL and that'll work until it doesn't, right?

Their subscription stuff is all, I was at the New York times, like a year or two ago and they were like, you know, everything that makes us money is still on the oldest parts of the system from the seventies, this, I may be misquoting them, but it was just like, yeah, stuff that was like built in the seventies, still working.

They've got specialized parts-- couple people who know how to make it work, but it's so hard--

Liz: The other one that we know for sure true is Ticketmaster, Ticketmaster still runs on evacs.

Heidi: And, we get requests all the time for a cobalt SDK.

Like, if you know any brilliant cobalt developers send them our way because I need a Cobalt SDK because we want to sell to insurance companies, they're very risk averse.

Charity: Of course.

Heidi: But, I think that it's really interesting, was it Corey Quinn who said legacy software or as I like to call it revenue generating software

Charity: Sounds like a Cory.

Heidi: I keep thinking about that, like legacy software is what makes us money and, we disrespect that--

Charity: I don't think it's that we disrespect that, it's that, I hope that the lesson that we've learned is, we can't allow things to become that legacy.

We have to continually upgrade them, there comes a point where it is approaching impossibility and like the bigger the gap gets and the more people who knew how to run it, die or leave, you know, the harder it becomes and you're just asymptotically approaching impossible.

And I hope that the lesson that we have learned is not, you know, don't have valuable things.

It's, if it's valuable, that means you have to change it often, constantly, keep it warm.

Liz: Yeah. Like churning, I love the saying that you have that like, shipping is our lifeblood

Charity: That's the intercom

Liz: Intercom, right? And I think a lot about, you know, how like sharks, right?

Like sharks, if they stop swimming, they stop getting oxygen and they die, right? Like, you got to keep moving!

Charity: It's like what you were saying, Heidi, the last thing we were doing together, where you were like, if you want to move safely with purpose, move fast, the slower you go, the less safe you will be, which is counter-intuitive to us because we come, you know, prebuilt with all of these notions about physics, but it is absolutely true.

Heidi: Right, we just need to elevate our physics understanding to like ice skating, good luck standing still and not falling over.

Like, standing still is the hardest thing.

Charity: Really is.

Liz: So, to touch briefly on another subject, how do we actually convince people to change their code?

How do we actually convince people to not just, say these spectators in the sport of observability or feature flagging, but instead to actually embrace modifying their code to empower themselves.

Heidi: I think the first thing that I always do, is ask people what they're scared of. We are mammals and we spend a lot of time being scared--

Charity: Fear driven development.

Heidi: Yes. And so when I say, hey, let's do this radical thing where you wrap all of your features in this code and you can, anybody can turn it off at any time.

They're like, yikes! I'm like, okay, so, lean into that yikes and tell me what you're scared of and here's some suggestions on how we're going to make that actually feel safer than what you have now.

So, when we say, okay, we're going to instrument everything and return enormous amounts of data, people are like, I don't even know how I process that.

Like, that is so much more data than I have right now, I will be overwhelmed by it and not be able to find the signal in the noise.

So then you can show them, okay, here is a change that you've made, here is the effect that it had. Here's how you can see it.

Liz: Hmm! So I guess that's kind of exposing to people that the things that they're most afraid of are already happening in production, and that there are safer ways to do things, right?

Charity: Everybody thinks that just because their alarms aren't going off, it means that like, nothing's breaking, ask anyone from ops, there are so many things broken in your production system at all times, you just don't know about yet.

Silence should make you afraid.

Heidi: Yes, it's like parenting, like, why has it gone so quiet?

Charity: Everybody leans so hard on the fear response.

Like, everybody who's selling software in our space at least is like, you know, you're going down! All those down times!

And like, honestly, I feel like I get that, that closes deals but, I feel like the adrenaline receptors in our brains are just kind of over-activated all the time these days and the real reason why people should want this software, is a very different feeling, it's a feeling of glee and joy and triumph and conquering and success and efficiency.

Like, the endurance of fire in your brain when you're solving a puzzle or you're doing a video game and you find the thing, you think you weren't expecting to, you know, you solve the quest!

Like that's what I associate with this stuff, but it's harder to market that.

Heidi: Sadly, the reason we're doing it is money

Charity: Right

Heidi: It is really hard to explain to your CFO--

Charity: It does sound more optional when you put it that way

Heidi: Yeah!

Charity: But, it'll make my life more like a video game.

Heidi: Yes, it will make your developers happier is, not something we've actually, we've done like token, would you like some sparkling water?

But we haven't done, would you like a four day work week? And one of these cost real money and one of them doesn't.

Charity: You know, it's so unfortunate that engineering managers aren't given like one budget for their people and their tools, because, I am still amazed that we're running Honeycomb with as few people as we are and we're only able to do that because we dog food so heavily, because we can move because we can see what we're doing.

Because we rarely make missteps because we rarely have shit that we have to back out and redo and that makes me so sad that most people have never had this experience and they think we're just like blowing vendors smoke up their ass, all right, now we're just like into the, "but what if users would just do what we told them to, all the time? Wouldn't that be great?"

Liz: It's so frustrating that we have to have people repeatedly run into the same walls that we've run into the further past 10 or 20 years.

And then they have to get those bumps in their heads before they're like, okay, wait, I am willing to try another way, right?

Charity: It is so satisfying though, hearing our users come out and say things like, oh my God!

I just adopted Honeycomb SLO's and deleted 90% of my paging alerts and we get woken up less and our users are happier.

Like, it's really satisfying to be able to amplify some of those voices now.

Heidi: Absolutely. And I think that, that's important for people who get woken up to here.

Charity: Yes! There is hope.

Heidi: Yeah, and I think that they will eventually become the people who are making the build versus buy decisions, I think that, you know, we're working through a generation in like a lot of social issues.

We're working through a bunch of people who are sort of stuck on, it sucked for me, it should suck for you too, instead of, it sucks for me, how can I make it better for you?

Charity: Gosh, I hope you're right! It's been so nice having you here, Heidi.

Heidi: Thank you

Charity: (giggling) You're just, a ray of sunshine! Liz, anything else you wanted to cover?

Liz: No, this was a fantastic conversation. I enjoyed it very much.

Heidi: Great! I got a couple of things.

Charity: Yeah!

Heidi: We've just announced a Honeycomb integration with LaunchDarkly

Charity: Oh, great!

Heidi: And, we're super excited and we'd like to encourage people to visit the LaunchDarkly site and see how you can use Honeycomb to see what you're doing with feature flags and get that super instant feedback, dopamine hit.

Charity: They compliment each other beautifully because you know, what's one of Honeycomb's things?

High cardinality. What is a high cardinality dimension?

Well, might be the monotonically infinitely increasing bill of ID, being able to break down by bill ID, being able to break down by feature flag and just go, " Oh, if I flip this flag on," what about all the variables? What happens to them? It's really kind of miraculous.

Liz: Now running those multi-variant experiments can be so costly and annoying and frustrating, right?

But having BubbleUp expose which feature flag values are most associated with the slow down or speed up, right? Like that's magic!

Heidi: It is magic! And it makes it safer for everybody.

So like, if you see something happen in Honeycomb and you can turn it off right away, then you know, you're like empowered

Liz: And also markers, the fact that we've supported markers for deployments, for ages and ages and ages, right?

But knowing when the feature flag flipped and having that indicated visually on your timeline, magical!

Charity: So fine grained, people are so used to quote, unquote, debugging, but it's like, they're trying to build this intricate castle in their head about what's happening?

When you can stop doing all that work in your head and just look at it and the tool, Oh my God! It's such a cognitive relief.

Heidi: Yeah. So, that's the thing that I'm really excited about right now.

I'm like, yay! We're getting a whole bunch of integrations out and they're going to make all of these tools so much more powerful.

And I'm really looking forward to seeing how the workflow thing helps people move their value along through their silos, like basically greasing the pipe with feature flags.

Charity: Yeah, for sure!

Liz: Excellent! Well, thank you for coming on Heidi.

Charity: Thanks Heidi.

Heidi: Thank you.